Talk:Modules/Meta

Dump of irc chat had about this subject.

22:47 <ashb> http://wiki.commonjs.org/wiki/Modules/Meta
22:47 <ashb> a few discussion points added
22:48 <kriskowal> going on about isMain again, eh?
22:49 <kriskowal> it *is* more concise for the common use case
22:49 <kriskowal> but i believe i already mentioned that require(require.main) is handy too
22:49 <ashb> for?
22:49 <kriskowal> e.g., self executing jack config files. i've done it.
22:49 <ashb> mmm lots of reasons i guess
22:49 <ashb> yeah
22:50 <ashb> exports.foo = ...; require('jackup'); and it just works
22:50 <kriskowal> actually, if (require.main == module.id) require("jackup").main([module.path])
22:51 <kriskowal> words to that effect anyway
22:51 <ashb> so i guess if module.id and require.id are both speced to be 'absolute/always load same module' thats okay
22:51 <kriskowal> is that not explicated in the spec?
22:51 * kriskowal checks
22:51 <ashb> implied, but not stated
22:51 <kriskowal> top-level
22:51 <ashb> 'The "module" object must have an "id" that is the top-level "id" of the module.'
22:52 <ashb> is all it says about module.id
22:53 <ashb> kriskowal: what does main() do with the path?
22:53 <kriskowal> top-level isn't the same thing as absolute, but has the effect you're talking about. absolute id's are beyond spec, but it makes sense to make them absolute if they're outside the module id domain
22:53 <kriskowal> main takes system.args, or faux args
22:53 <ashb> kriskowal: yeah, i think the exact mechanism doesn't need to be specified, just hte intent that you get the right module
22:54 <ashb> k so for the jackup example isMain would work too
22:54 <kriskowal> right, so the question is whether you want two channels to the same data.
22:54 <ashb> yeah
22:54 <kriskowal> unless it's your expectation for isMain to be lazily evaluated on require.main == module.id
22:55 <ashb> but so far the only real example usage people have given me for require.main is what you've just shown
22:55 <kriskowal> or as a function call that closes on those values.
22:55 <ashb> if anyone can give me one real example i'll drop my quest for isMain :)
22:55 <ashb> kriskowal: i envisaged it as a ro prop rather than a fn
22:56 <kriskowal> suppose that you're in another module, and you want to see the main module's exports
22:56 <ashb> should probably make .main and .id perm, read-only properties
22:56 <kriskowal> in a system where the convention is for the main module to be a config file
22:56 <ashb> kriskowal: yeah that makes sense
22:57 <kriskowal> let's not take the "if nobody's doing it for real yet no one will ever want to" angle. the purpose of a language or library is to permit programs to be written unforseen by the creators of the language or library.
22:57 <ashb> i do wonder slightly if |require.main| is the wrong name/place for it tho
22:57 <ashb> kriskowal: this is true. but we also don't want to go the other way of specing everything just because it might be useful to someone
22:57 <kriskowal> the reasoning is that it's a place that works with many variations on the loader.
22:58 <ashb> but consider isMain dropped
22:58 <kriskowal> the idea is that sometimes "require" is a global object, and "module" is always a per-module object.
22:58 <kriskowal> although, in some loaders "require" is per-module too
22:59 <ashb> yeah i've switched it to per module in flusspferd
22:59 <ashb> cos the way we had it before broke JITing
22:59 <kriskowal> ihab pointed out that we could have conflated require and module using the same mechanisms in gpsee and helma that were used to discover the calling module for these other properties, but i don't intend to rock the boat. it's a little more readable anyway.
22:59 <ashb> kriskowal: so module.id should certainly be RO, and i guess require.main should be too?
23:00 <kriskowal> i certainly wouldn't expect things to work if it were assigned too
23:00 <ashb> what mechanism is that?
23:00 <kriskowal> i'm not intimate with the details, but i presume it was through dynamic scope traversal only possible from c
23:01 <ashb> okay. finaly comment on the proposal is i want to remove all mentions of 'sanbox'
23:01 <ashb> specifially i dont see why the spec mandates that those properties must not be present in a sandbox
23:02 <kriskowal> in a secure sandbox
23:02 <kriskowal> .paths discloses information about the structure of your file system and probably even your user name, increasing the attack surface of the system
23:03 <ashb> yes but there are many types of secure sandbox
23:03 <kriskowal> we should probably revisit the issue with security experts when we actually have a real sandbox to talk about.
23:03 <kriskowal> like, one :P
23:03 <ashb> thats kinda my thinking
23:04 <ashb> since 'a secure sandbox' might just mean loading no new code to one person
23:04 <ashb> where as it might mean 'no FS access at all and no info leak' to another
23:04 <kriskowal> that's where dependency injection comes in
23:05 <kriskowal> i haven't been able to do hermetic eval in narwhal yet, due to strangeness of rhino. can't wait to have a real Object.freeze et al
23:05 <ashb> yeah, in the first module.path is allowed
23:05 <ashb> but: 'The "path" property must not exist in a sandbox.'
23:06 <ashb> tbh i basically see (ultra-)secure sandboxes as a documented subset of commonJS
23:06 <kriskowal> it's a little more strict than that
23:07 <ashb> oh?
23:07 <kriskowal> if we're talking about modules and standard libraries, in the interest of real interoperability, those modules must work in a secure sandbox
23:08 <kriskowal> so, while engine specific components can be written in the context of commonjs related stuff, those modules are not commonjs compliant, and really can't be shared in the absolute sense
23:08 <kriskowal> i think the general idea is that application developers can do whatever they need, but we're promising that the standard library will work in a wide variety of contexts.
23:09 <ashb> yeah. i just dont like the fact we are mandating that something must not be possible in X, when we haven't really defined X
23:09 <kriskowal> it's better to be safe than future incompatible
23:10 <Wes_> Mmmm much better
23:10 * Wes_ was seeing stars
23:10 <kriskowal> that happens a lot in LA
23:10 <ashb> kriskowal: hmmm i guess you're right
23:11 <kriskowal> so, i think that Modules/Meta is ratified. i guess the status line never got updated.
23:11 <kriskowal> would you say that's okay?
23:11 <ashb> tho in this specific example (module.path) i can't see how forbidding an optional property could be incompatible
23:12 <ashb> kriskowal: whith one slight amendment as to the intent/behaviour of module.id/require.main
23:12 <kriskowal> perhaps explication of intent would be the right word. i think the normative text is as strict as we can make it without defining "absolute"
23:12 <ashb> just some verbage such as 'require.main can be passed to require() and loading the main program module'
23:12 <kriskowal> perhaps you can add something to the introduction or add a footnote
23:13 <kriskowal> ah, that would work
23:13 <ashb> and similar for module.id
23:13 <ashb> and i guess that the forms must be normalize so that .main == .id is true for the main script
23:13 <kriskowal> require(require.main) must return the exports of the main module
23:13 <kriskowal> require(module.id) must be equivalent to exports
23:14 <ashb> even when called from outside the current module
23:14 <kriskowal> even when passed through another module
23:14 <kriskowal> aye
23:14 <ashb> with those changes, yes i'm happy with it
23:14 * Wes_ is caught up
23:14 <kriskowal> i'd say go for it.
23:14 <Wes_> Not super happy with require.main -- but there isn't a better solution that doesn't involve polluting namespace: lesser of two evils wins
23:15 <kriszyp> so kriskowal, I sent you my work that I did on adding async/comet support to jack/narwhal. Is there anyone else I should send it to for review?
23:15 <Wes_> I'm also not happy with sandboxy "must not" -- but agree with KK pragmatism on subject
23:15 <ashb> Wes_: the other thing i thought was something on system module
23:15 <kriskowal> kriszyp: got email
23:15 <Wes_> ashb: possibly, but it doesn't seem like loading a module to get that seems reasomable either
23:15 <kriskowal> as far as i know tlrobinson isn't ready to evaluate promises.
23:15 <kriskowal> of course, neither am i :P
23:16 <ashb> Wes_: yeah it doesn't
22:47 <ashb> http://wiki.commonjs.org/wiki/Modules/Meta
22:47 <ashb> a few discussion points added
22:48 <kriskowal> going on about isMain again, eh?
22:49 <kriskowal> it *is* more concise for the common use case
22:49 <kriskowal> but i believe i already mentioned that require(require.main) is handy too
22:49 <ashb> for?
22:49 <kriskowal> e.g., self executing jack config files. i've done it.
22:49 <ashb> mmm lots of reasons i guess
22:49 <ashb> yeah
22:50 <ashb> exports.foo = ...; require('jackup'); and it just works
22:50 <kriskowal> actually, if (require.main == module.id) require("jackup").main([module.path])
22:51 <kriskowal> words to that effect anyway
22:51 <ashb> so i guess if module.id and require.id are both speced to be 'absolute/always load same module' thats okay
22:51 <kriskowal> is that not explicated in the spec?
22:51 * kriskowal checks
22:51 <ashb> implied, but not stated
22:51 <kriskowal> top-level
22:51 <ashb> 'The "module" object must have an "id" that is the top-level "id" of the module.'
22:52 <ashb> is all it says about module.id
22:53 <ashb> kriskowal: what does main() do with the path?
22:53 <kriskowal> top-level isn't the same thing as absolute, but has the effect you're talking about. absolute id's are beyond spec, but it makes sense to make them absolute if they're outside the module id domain
22:53 <kriskowal> main takes system.args, or faux args
22:53 <ashb> kriskowal: yeah, i think the exact mechanism doesn't need to be specified, just hte intent that you get the right module
22:54 <ashb> k so for the jackup example isMain would work too
22:54 <kriskowal> right, so the question is whether you want two channels to the same data.
22:54 <ashb> yeah
22:54 <kriskowal> unless it's your expectation for isMain to be lazily evaluated on require.main == module.id
22:55 <ashb> but so far the only real example usage people have given me for require.main is what you've just shown
22:55 <kriskowal> or as a function call that closes on those values.
22:55 <ashb> if anyone can give me one real example i'll drop my quest for isMain :)
22:55 <ashb> kriskowal: i envisaged it as a ro prop rather than a fn
22:56 <kriskowal> suppose that you're in another module, and you want to see the main module's exports
22:56 <ashb> should probably make .main and .id perm, read-only properties
22:56 <kriskowal> in a system where the convention is for the main module to be a config file
22:56 <ashb> kriskowal: yeah that makes sense
22:57 <kriskowal> let's not take the "if nobody's doing it for real yet no one will ever want to" angle. the purpose of a language or library is to permit programs to be written unforseen by the creators of the language or library.
22:57 <ashb> i do wonder slightly if |require.main| is the wrong name/place for it tho
22:57 <ashb> kriskowal: this is true. but we also don't want to go the other way of specing everything just because it might be useful to someone
22:57 <kriskowal> the reasoning is that it's a place that works with many variations on the loader.
22:58 <ashb> but consider isMain dropped
22:58 <kriskowal> the idea is that sometimes "require" is a global object, and "module" is always a per-module object.
22:58 <kriskowal> although, in some loaders "require" is per-module too
22:59 <ashb> yeah i've switched it to per module in flusspferd
22:59 <ashb> cos the way we had it before broke JITing
22:59 <kriskowal> ihab pointed out that we could have conflated require and module using the same mechanisms in gpsee and helma that were used to discover the calling module for these other properties, but i don't intend to rock the boat. it's a little more readable anyway.
22:59 <ashb> kriskowal: so module.id should certainly be RO, and i guess require.main should be too?
23:00 <kriskowal> i certainly wouldn't expect things to work if it were assigned too
23:00 <ashb> what mechanism is that?
23:00 <kriskowal> i'm not intimate with the details, but i presume it was through dynamic scope traversal only possible from c
23:01 <ashb> okay. finaly comment on the proposal is i want to remove all mentions of 'sanbox'
23:01 <ashb> specifially i dont see why the spec mandates that those properties must not be present in a sandbox
23:02 <kriskowal> in a secure sandbox
23:02 <kriskowal> .paths discloses information about the structure of your file system and probably even your user name, increasing the attack surface of the system
23:03 <ashb> yes but there are many types of secure sandbox
23:03 <kriskowal> we should probably revisit the issue with security experts when we actually have a real sandbox to talk about.
23:03 <kriskowal> like, one :P
23:03 <ashb> thats kinda my thinking
23:04 <ashb> since 'a secure sandbox' might just mean loading no new code to one person
23:04 <ashb> where as it might mean 'no FS access at all and no info leak' to another
23:04 <kriskowal> that's where dependency injection comes in
23:05 <kriskowal> i haven't been able to do hermetic eval in narwhal yet, due to strangeness of rhino. can't wait to have a real Object.freeze et al
23:05 <ashb> yeah, in the first module.path is allowed
23:05 <ashb> but: 'The "path" property must not exist in a sandbox.'
23:06 <ashb> tbh i basically see (ultra-)secure sandboxes as a documented subset of commonJS
23:06 <kriskowal> it's a little more strict than that
23:07 <ashb> oh?
23:07 <kriskowal> if we're talking about modules and standard libraries, in the interest of real interoperability, those modules must work in a secure sandbox
23:08 <kriskowal> so, while engine specific components can be written in the context of commonjs related stuff, those modules are not commonjs compliant, and really can't be shared in the absolute sense
23:08 <kriskowal> i think the general idea is that application developers can do whatever they need, but we're promising that the standard library will work in a wide variety of contexts.
23:09 <ashb> yeah. i just dont like the fact we are mandating that something must not be possible in X, when we haven't really defined X
23:09 <kriskowal> it's better to be safe than future incompatible
23:10 <Wes_> Mmmm much better
23:10 * Wes_ was seeing stars
23:10 <kriskowal> that happens a lot in LA
23:10 <ashb> kriskowal: hmmm i guess you're right
23:11 <kriskowal> so, i think that Modules/Meta is ratified. i guess the status line never got updated.
23:11 <kriskowal> would you say that's okay?
23:11 <ashb> tho in this specific example (module.path) i can't see how forbidding an optional property could be incompatible
23:12 <ashb> kriskowal: whith one slight amendment as to the intent/behaviour of module.id/require.main
23:12 <kriskowal> perhaps explication of intent would be the right word. i think the normative text is as strict as we can make it without defining "absolute"
23:12 <ashb> just some verbage such as 'require.main can be passed to require() and loading the main program module'
23:12 <kriskowal> perhaps you can add something to the introduction or add a footnote
23:13 <kriskowal> ah, that would work
23:13 <ashb> and similar for module.id
23:13 <ashb> and i guess that the forms must be normalize so that .main == .id is true for the main script
23:13 <kriskowal> require(require.main) must return the exports of the main module
23:13 <kriskowal> require(module.id) must be equivalent to exports
23:14 <ashb> even when called from outside the current module
23:14 <kriskowal> even when passed through another module
23:14 <kriskowal> aye
23:14 <ashb> with those changes, yes i'm happy with it
23:14 * Wes_ is caught up
23:14 <kriskowal> i'd say go for it.
23:14 <Wes_> Not super happy with require.main -- but there isn't a better solution that doesn't involve polluting namespace: lesser of two evils wins
23:15 <kriszyp> so kriskowal, I sent you my work that I did on adding async/comet support to jack/narwhal. Is there anyone else I should send it to for review?
23:15 <Wes_> I'm also not happy with sandboxy "must not" -- but agree with KK pragmatism on subject
23:15 <ashb> Wes_: the other thing i thought was something on system module
23:15 <kriskowal> kriszyp: got email
23:15 <Wes_> ashb: possibly, but it doesn't seem like loading a module to get that seems reasomable either
23:15 <kriskowal> as far as i know tlrobinson isn't ready to evaluate promises.
23:15 <kriskowal> of course, neither am i :P
23:16 <ashb> Wes_: yeah it doesn't