Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-10-19:

[3:41] <Wes-> deanlandolt: ping
[3:42] <deanlandolt> Wes- pong
[3:43] <Wes-> deanlandolt: I'm writing a browser-side module system tonight, trying to demonstrate the proposal I proposed today. I'm hoping I can write the server-side component in JS. Is reading a file, processing a get query, and generating output a realistic goal for me in one night?
[3:43] <Wes-> Or I should keep the example server-side code in shell script?
[3:43] <deanlandolt> heh...well it would be if you said /tomorrow/ night :)
[3:44] <Wes-> deanlandolt: *lol* - maybe we'll revisit that soon then!
[3:44] <deanlandolt> i'm just landing fs, stream and http ops (jacked wholesale from promised-io of course) but i haven't touched the gpsee side of things yet
[3:44] <Wes-> deanlandolt: I got side tracked, haven't ported jack to GPSEE yet. It *should* be trivial, FWIW
[3:44] <deanlandolt> just pushed an initial pass (and i'm cleaning up the file stuff)...if you have a copy of narwhal handy you should be able to make http requests
[3:44] <Wes-> I started, then got the idea for this module system
[3:44] <deanlandolt> node should work too (haven't tested it yet though)
[3:45] <deanlandolt> oh, well you don't need jack or anyting
[3:45] <deanlandolt> just the javascript commons
[3:45] <Wes-> :D
[3:45] <deanlandolt> has a nice ring to it
[3:45] * Wes- agrees
[3:45] <Wes-> Did you have a chance to read the AMD thread today?
[3:45] <Wes-> If not, I understand, it's getting insane
[3:46] <deanlandolt> interestingly the requests themselves have the same structure as jsgi (the request and response objects are so very simple and nice for an http client)
[3:46] <deanlandolt> yeah, i read the whole thing
[3:46] <Wes-> But I think I have figured out the problem - people want require(X) to both return the module memo and be a module loader
[3:46] <Wes-> I think that's wrong
[3:46] <Wes-> I think require(X) reads the module memo
[3:46] <Wes-> The fact that it loads transparently on the server is an optimization
[3:46] <deanlandolt> define is the loader?
[3:46] <Wes-> I don't care what you call it, but require(X) ain't it
[3:46] <Wes-> I'm not sure I get "define"
[3:47] <Wes-> but the "thing" is the equivalent of loadModule in es-harmony
[3:47] <deanlandolt> i don't care about the name, but i do agree there's a separation of concerns there we should clearly delineate
[3:47] <Wes-> Also, I figured out a trivial way to express dependencies in a backwards-compatible way
[3:47] <deanlandolt> ahh, yeah, you'd said that earlier...that does make sense to me
[3:47] <Wes-> We have been looking at the problem backwards: caller specifies
[3:47] <Wes-> We should be doing callee specifies
[3:48] <deanlandolt> yeah...well the callee would know
[3:48] <Wes-> Then modules just need to have a module.dependencies = [ "moduleA", "moduleB" ] array
[3:48] <Wes-> exactly!@
[3:48] <deanlandolt> that's how dojo does it
[3:48] <deanlandolt> and many others
[3:48] <Wes-> And since the callee knows, we don't need to conflate with the loader syntax
[3:48] <deanlandolt> /that's/ what define means to me
[3:48] <deanlandolt> (but that's not really how it's being used, as far as i gather)
[3:48] <Wes-> And as soon as we separate the loader, the depend decl, and the memo reader...
[3:48] <Wes-> suddenly the memo reader is plain require(X)
[3:49] <Wes-> and all the code works on the server without change
[3:49] <Wes-> (becase the server just ignores module.dependencies array)
[3:49] <deanlandolt> yeah, i can actually grok that
[3:49] <deanlandolt> very nice
[3:49] <Wes-> Now if I only I can convince the people with a vested interest that the extra syntax is unnecessary
[3:50] <deanlandolt> :)
[3:50] <Wes-> And that you can load *all* the depends at once, rather than trying to do so piecemeal per require call
[3:50] <deanlandolt> it sounds like everything's on the table right now, and everyone's pretty much on board to revisit...
[3:50] <deanlandolt> so now's the time
[3:50] <Wes-> (which has weird implications that Kris Kowal and co are better at describing than I)
[3:50] * Wes- ndos
[3:50] <Wes-> I think all we need to do is add module.depends to the module spec
[3:51] <deanlandolt> yeah, the piecemeal thing doesn't make sense...as was pointed out in the thread several times -- i fyou want a plugin loader, write a plugin loader
[3:51] <Wes-> Could even make it optional
[3:51] <Wes-> Then you need a module loader, which is a separate thing entirely
[3:51] <Wes-> Of course, the server module loader ("magic") is inappropriate for the client
[3:51] <Wes-> But that doesn't mean you have to spray loader syntax through the modules
[3:52] <deanlandolt> damn strait
[3:52] <Wes-> Also, you can actually implement a *loader* as SCRIPT tags + a body.onload event
[3:52] <Wes-> This is analogous to the module keyword in es-h modules
[4:04] <Wes-> deanlandolt: stupid question, do you know is there a way to to get at another module's module variable in the spec anywhere?
[4:05] <deanlandolt> not that i'm aware of, no
[4:05] <Wes-> Interesting, that makes it a smidge harder to dig for dependencies :)
[4:05] <Wes-> Only a smidge, though
[4:23] <Wes-> Ah, yes, of course - since I make a module free var for the module, I have a reference to that in the module init code, and can return that upstream for dependency resolution.
[4:23] <Wes-> Anybody got a nice set of inter-dependent modules I can use for testing a loader?
[4:48] <Wes-> Holy crap! I Just figured out to make a mental jump from iterative to CPS!
[4:48] <Wes-> http://pastebin.mozilla.org/821207
[6:33] <Wes-> I normally implement require with semantics that have it close over it's module id, so it knows how to load relative modules
[6:34] <Wes-> Is there anything preventing me from simply using the module.id upvar?
[7:18] <Hadaka> I'll write a mail to the commonjs group about promises today

 

 

Logs by date :