Hopbot log for 2008-10-02 - Helma IRC channel: #helma on irc.freenode.net

2008-10-02:

[9:29] <hannesw> Any opinions on renaming issues in Helma NG?
[9:29] <hannesw> http://groups.google.com/group/helma-ng/browse_frm/thread/b4db68575a3fa729
[9:29] * simono will read it after lunch
[9:47] <simono> first thing that came to my mind was load and loadAll
[9:48] <simono> if u dont like load at all then i would rather have require/include then load/include
[10:49] <hannesw> It's not that I absolutely dislike load(), it's just that I prefer require()...
[11:06] <Helma7> you around chris?
[11:08] <zumbrunn> yep
[11:08] <zumbrunn> now I am
[11:09] <mindlike> you ever get helma and flex talking together?
[11:10] <zumbrunn> I just experimented with helma generating flex code
[11:10] <mindlike> heh interesting
[11:10] <mindlike> is that using macros?
[11:11] <zumbrunn> don't remember if I used macros
[11:11] <zumbrunn> probably did
[11:12] <zumbrunn> it was quite a long time ago
[11:12] <mindlike> eh nm
[11:12] <mindlike> i can't remember where but i think i saw some helma derived project using flex in the help area or example
[11:12] <mindlike> but it was like a month ago
[11:13] <zumbrunn> I don't remember ever seeing anything like that
[11:13] <zumbrunn> in a helma help area or a flex help area?
[11:13] <mindlike> well there's something called xml-rpc-java
[11:13] <mindlike> or a few java amfphp libs
[11:14] <mindlike> thats all you need then you can write independent ui's .. but automating like you attempted .. thats nice
[11:14] <zumbrunn> apache xml-rpc is actually based on a very old version of helma
[11:14] <mindlike> oh yeah so here's my technical challenge for the day :-)
[11:15] <mindlike> that is if you can get to it
[11:16] <zumbrunn> hannesw, I noticed that in the require_include git branch, for example webapp currently uses syntax like require('core.string')
[11:16] <zumbrunn> http://github.com/hns/helma-ng/tree/require_include/modules/helma/webapp.js
[11:17] <zumbrunn> shouldn't that be include('core.string') ?
[11:20] <hannesw> nope - include() sets all the properties from the module in the calling scope
[11:21] <hannesw> but core.string just adds to String and String.prototype, so no need to use include()
[11:22] <hannesw> so include is like importFromModule("foo", "*"). I guess you assumed the semantic was "load the module, but don't return anything"?
[13:51] <zumbrunn> sorry for asking a question and then just walking away
[13:51] <zumbrunn> I assumed the intention there was to import those modules into the current scope
[13:52] <zumbrunn> in the case of require('core.string') and include('core.string') that doesn't make a difference, I guess
[13:53] <zumbrunn> but doesn't require('helma.webapp.request'); intend to import into the current scope?
[13:53] <zumbrunn> I guess I have to go and take another look at that code
[13:56] <zumbrunn> ok, I see, they clearly don't intend to import
[14:58] <hannesw> loadModule(), or eventually require(), don't set anything in the current scope.
[14:59] <hannesw> It's only when you use them in an assignment that you get a reference.
[15:00] <zumbrunn> right, like "my" Modules
[15:00] <hannesw> yep
[15:00] <zumbrunn> vs "module" which would import
[15:00] <hannesw> do you really think that Modules/module duality is a good idea?
[15:01] <hannesw> I think it is confusing like hell
[15:01] <zumbrunn> then it is probably not a good idea
[15:01] <hannesw> I'd rather do something like include(Modules.foo.bar)
[15:02] <hannesw> or just Modules.foo.bar to just evaluated the module...
[15:02] <hannesw> wait, I'm confused ... :-)
[15:02] <zumbrunn> no your are not :-)
[15:03] <zumbrunn> you just think you are confused ;-)
[15:03] <hannesw> would module set anything in the current scope?
[15:03] <zumbrunn> yes, like your include(Modules.foo.bar) above
[15:04] <hannesw> ok, I got it now
[15:07] <zumbrunn> like you said yourself, ...
[15:07] <zumbrunn> var foo = require('helma.foo');
[15:08] <zumbrunn> ...seems semantically wrong/confusing
[15:08] <hannesw> why? and when did I say that?
[15:08] <hannesw> ah, ok, i know :-)
[15:08] <hannesw> yes, but it's not that bad, is it?
[15:09] <zumbrunn> well, that bit is pretty bad in my opinion
[15:09] <zumbrunn> but that's really the only bit I dislike
[15:10] <hannesw> why do you think it is pretty bad?
[15:11] <zumbrunn> require somehow just doesn't fit for an assigment
[15:11] <hannesw> I don't see that. Any function can return a value...
[15:11] <hannesw> It's true that the name doesn't hint at that
[15:14] <zumbrunn> require is better than load otherwise though, since it makes clear that the loading only happens once
[15:14] <hannesw> yes, also true.
[15:25] <zumbrunn> var foo = refer('helma.foo');
[15:25] <zumbrunn> obtain('something.to.import');
[15:26] <hannesw> nope :-)
[15:27] <zumbrunn> :-)
[15:27] <hannesw> no like
[15:27] <hannesw> gotta run.
[15:27] <zumbrunn> ok
[15:28] <hannesw> cu later
[15:40] <leefaus> what is the target for ng? should i be using that for my prototypes?
[15:42] <zumbrunn> ng is alpha
[15:42] <zumbrunn> but more modern and leaner
[15:42] <leefaus> so january?
[15:43] <zumbrunn> there is no target date like that
[15:43] <zumbrunn> it's ready when it's ready :-)
[15:43] <leefaus> so it could be said that it is production ready now :)
[15:44] <zumbrunn> one could say that, yes :-)
[15:44] <zumbrunn> in other words, if for what you want, it isn't ready now, then you shouldn't use it yet
[15:45] <leefaus> :)

 

 

In the channel now:

Logs by date: