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

2009-02-16:

[9:37] <hannesw> zumbrunn: what new with the serverjs discussion?
[9:38] <zumbrunn> recent discussion regarding the modules has been about the exact nature of the object returned by require
[9:39] <zumbrunn> whether that should be mutable or not,
[9:39] <zumbrunn> whether it should be able to be a snapshot,
[9:39] <zumbrunn> whether it should always have to be the exact same object that was passed into the module as exports
[9:41] <zumbrunn> I think if we mandate a specific behavior for this detail, then we should also discuss the behavior of the global scope in modules again
[9:41] <zumbrunn> the two aspects are kind of on the same level I think
[9:41] <zumbrunn> neither needs to be standardized for the standard library itself
[9:42] <zumbrunn> but we need a standard or conventions for both, if we want to have a shared platform to build frameworks on
[9:43] <zumbrunn> also, whether the object returned by require should be able to be a proxy to the exports object, instead of a direct reference
[9:44] <zumbrunn> for example, it could be an instance of the module's exports object
[9:44] <zumbrunn> (inheriting via the prototype chain, much like modules scopes inherit their global scope now in helma ng)
[9:45] <hannesw> ok
[9:46] <zumbrunn> or a proxy object that uses method missing and future defineProperties behavior (which we do not yet have in browsers) to be able to control access to the modules exports
[9:47] <zumbrunn> and as a workaround for that capability not being available yet, peter was even suggesting returning a function instead of an object
[9:47] <hannesw> I'm not so convinced by securable modules anymore
[9:47] <hannesw> i think it's really a huge hack
[9:48] <hannesw> designed to work in the browser, but otherwise crippled
[9:48] <zumbrunn> isn't it just a subset of the helmatic modules?
[9:48] <hannesw> it's similar.
[9:48] <hannesw> one example for why i think it's crippled:
[9:48] <hannesw> why do you have to pass it the exports object?
[9:49] <zumbrunn> I agree it is crippled, in the sense that we would need to agree to standardize more details to be able to actually have a platform to implement frameworks on top of
[9:49] <hannesw> because the browser implementation is expected to be wrapped in a closure function by the loader
[9:49] <hannesw> so you can't just define the exports object in the module, which would be much more flexible
[9:50] <hannesw> e.g. var exports ={ foo: "foo" }
[9:50] <zumbrunn> the requirement to pass in the exports object was due to circular dependencies, I thought
[9:50] <hannesw> how? I don't think so
[9:51] <zumbrunn> yes, so that the exports object is available to the "modules management system" before the module has completed running through its code
[9:52] <zumbrunn> which allows it to resolve circular dependencies
[9:52] <zumbrunn> I thought that was the only reason for that requirement
[9:53] <hannesw> i don't think that's true
[9:54] <hannesw> if you load on demand, it doesn't matter if you get the exports object before or after evaluation. you have to evaluate on demand anyway
[9:55] <hannesw> i.e. require() will load the module and return the exported properties. doesn't matter if require() has the exports object at the beginning or the end
[9:55] <hannesw> well, i'll just read up on the last week i missed :-)
[9:56] <zumbrunn> what if A requires B which requires C which requires A?
[9:56] <hannesw> then i'll finish with the helma ng req/res refactoring
[9:56] <zumbrunn> does that currently work in ng?
[9:57] <hannesw> yes, unless you actually access something in the imported module before it's evaluated
[9:57] <hannesw> wait, i guess you're right
[9:58] <hannesw> ok, i see your point now. in helma ng, we also register the module scope before evaluating it in order for cyclic dependencies to work.
[9:58] <hannesw> ok, so you are right here
[9:59] <hannesw> ok, so that concern wasn't valid.
[9:59] <hannesw> so again, no problem with securable modules :-)
[10:00] <hannesw> what about the other areas? standard libraries?
[10:00] <hannesw> anything byond pure talk?
[10:00] <zumbrunn> only little that I have seen so far
[10:02] <hannesw> maybe I'll implement securable modules today in helma ng. should be easy.
[10:04] <zumbrunn> hopefully without crippling helma ng ;-)
[10:05] <zumbrunn> since I think securable modules as they are currently proposed alone do not offer sufficient functionality compare to what we have now in ng
[10:05] <hannesw> i think we can implement what we have on top of that
[10:05] <hannesw> otherwise, it would definitely be crippled imo
[10:06] <zumbrunn> yes
[10:06] <hannesw> i don't want to use require() as is, and i don't want to use exports as is
[10:07] <zumbrunn> yes, if we want to be able to really run things that we write on top of other implementations, we will need to standardize more of the functionality we have now in ng
[10:08] <zumbrunn> which is why I'm arguing to talk about standardizing on two separate levels
[10:09] <zumbrunn> one for the standard library
[10:09] <zumbrunn> and one for a shared platform to build frameworks on top of
[10:15] <hannesw> I'm not sure i'm following you
[10:16] <hannesw> don't we just need "more standardization"?
[10:22] <hannesw> Something else: I uploaded a screenshot of a more standard-gobi-like helma.org skinset:
[10:23] <hannesw> http://dev.helma.org/wiki/helma.org+redesign/
[10:23] <hannesw> have a look and tell me what you think
[10:55] <zumbrunn> sticking with the black and white logo is better, I think
[10:55] <zumbrunn> or something like this: http://dev.helma.org/static/files/3130/helma-proposal-blue-alternative.png
[10:56] <zumbrunn> well, yes, just more standardization
[10:57] <zumbrunn> but that might not be easily achievable
[10:58] <zumbrunn> since there are probably justified reasons to have different requirements for how exactly modules behave
[10:58] <zumbrunn> depending on the environment/domain of where javascript is used
[11:01] <zumbrunn> so, I think defining conventions for different domains makes sense
[11:02] <zumbrunn> for example, we wouldn't want all our modules to be restricted to the limited behavior they may need to have when used as secured modules in a sandbox
[17:20] <klem> anybody time to support a rookie?
[18:10] <zumbrunn> klem: sure, but you left to early
[18:10] <zumbrunn> you'll need to come back here

 

 

In the channel now:

Logs by date: