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

2010-10-25:

[12:31] <WesMac> kriszyp: ping
[12:32] <kriszyp> hi
[12:33] <WesMac> kriszyp: Was curious if you were planning on updating Transports/* (etc) at all this week?
[12:33] <WesMac> kriszyp: I'm working on parallel work, hoping not to cross streams
[12:33] <kriszyp> I wasn't planning on doing anything
[12:34] <WesMac> kriszyp: I also discovered that modules should be written without the trailing semi-colon at the declaration
[12:34] <WesMac> kriszyp: It makes multi-transport composition at little easier, as well at making it easier to validate invalidly formatted files (trailing code after module decl)
[12:35] <WesMac> (did you already notice that?)
[12:35] <kriszyp> no
[12:37] <WesMac> leaving it off, XHR-style or server-side loaders can validate with eval( "(" + the file + ")" ) -- files with trailing code after definition will throw
[15:11] <deanlandolt> Wes- i think the main module's id was the old behavior...i seem to recall everyone (involved in the discussion) agreeing to change it
[15:28] <WesMac> deanlandolt: Thanks, kinda confused on that one, so GPSEE is "right", at least defacto if not dejure?
[15:28] <deanlandolt> yeah, i don't know if it's dejure...thought i saw something in 1.1
[15:28] <deanlandolt> The "require" function may have a "main" property that is read-only, don't delete and represents the top-level "module" object of the program. If this property is provided, it must be referentially identical to the "module" object of the main program.
[15:28] <deanlandolt> yeah, that's right
[15:28] <deanlandolt> that's strait out of 1.1
[15:30] <deanlandolt> so yeah, 'tis dejure, which is nice
[15:41] <deanlandolt> WesMac: another possible goal for 2.0: To clearly distinguish the needs of a module authoring format from Transport-level packaging formats.
[15:42] <deanlandolt> one module per file, no slot for id (as it is irrelevant)
[15:42] <deanlandolt> no global define
[15:49] <deanlandolt> oh, i just noticed that your draft allows loading modules directly from a CDN...that's /huge/
[15:50] <deanlandolt> though, perhaps it's best to use something like AMD for loading packaged CDN code at runtime
[15:51] <deanlandolt> still, some pretty big advantages (for browsers) to be able to point to a /2.0 module at a github.com/*/raw url
[16:49] <deanlandolt> WesMac: one other thing RequireJS does that we /probably/ ought to have in Modules/2.0 or something related: http://github.com/ajaxorg/editor/blob/master/src/ace/VirtualRenderer.js#L21
[16:50] <deanlandolt> that's been a constant source of pain...it may be too burdensome to lump it together with Modules but it's intertwingled
[16:51] <deanlandolt> hmm...if module.load could do more than sourceCode maybe?
[16:52] <deanlandolt> handling the ext would be awkward though
[18:13] <WesMac> deanlandolt: I am hoping something like that can be addressed with an extension written in fs-base + streams in the future. My proposed require.canonicalize hands the hard part -- translating a module-relative path to a URI or filename that fs-base.openRaw() could handle
[18:13] <WesMac> BTW, adding "readAll()" to fs-base would finish that, then we could
[18:14] <WesMac> module.prototype.resource = function (name) { return require('fs-base').open(require.canonicalize(name)).readAll() }
[18:16] <WesMac> but that entrains at least fs-base and binary, maybe streams depending on the implementation
[18:17] <WesMac> deanlandolt: maybe "readAllBytes" could come along with your cross-platform binary module! You could monkey-patch require("fs-base") ! :)
[18:22] <deanlandolt> WesMac: fs.read, as defined by filesystem/a, does a pretty good job of that...and it can be shimmed into node nicely
[18:23] <deanlandolt> but yeah, canonicalize is really what we need :)
[19:10] <WesMac> deanlandolt: I have seen use cases galore for module.prototype, but not exports.prototype. Have seen slight anti-use-case for exports.prototype, thinking about dropping it. Do you have an opinion?
[19:13] <deanlandolt> i'd imagine with returnable exports exports.prototype would mean very little anyway
[19:14] <deanlandolt> in fact, i'd go as far as to say dropping "exports" is a servicable option
[19:14] <deanlandolt> with wrappers it just gets in the way
[19:14] <deanlandolt> and it stinks of `this`
[19:24] <deanlandolt> i know this would never fly...but still, what value is there to providing exports if it can be returned?
[19:26] <WesMac> deanlandolt: "i'd imagine..." -- that's exactly what was I thinking
[19:26] <WesMac> deanlandolt: providing exports is important for circular dependencies
[19:27] <deanlandolt> hmm, i guess return exports; wouldn't quite fly there
[19:27] <WesMac> returning exports has semantic problems if the module is part of a circular dependency list, but the problems are manageable, I think. Mostly "circular deps won't do what you think they will if you return exports, so don't do that"
[19:28] <deanlandolt> cool
[19:28] <deanlandolt> well, in any event, i can't think of a legit use for exports.prototype off the top of my head
[19:29] <WesMac> okay, that's good. I thought of a use for module.prototype and said, "what's good for module must be good for exports!" but I think I was wrong

 

 

Logs by date :