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

2010-10-23:

[6:06] <Dantman> "CommonJS (354)"
[16:10] <Wes-> deanlandolt: you around?
[17:03] <deanlandolt> Wes- hey, sorry, doing some work on the house
[17:03] <Wes-> deanlandolt: Can you send me your notes? I'm going to try bashing out a spec, see how far I get
[17:04] <deanlandolt> yeah, let me hop on the work computer
[17:09] <Wes-> FWIW, we're going to need allies who thing /2.0 is a good idea. ;)
[17:09] <deanlandolt> yeah, no doubt...
[17:10] <deanlandolt> i mean, i'm still not convinced we even /need/ 2.0 :)
[17:10] <deanlandolt> but if we're talking about blessing a wrapping we're talking about 2.0...your arguments are unasailable
[17:12] <deanlandolt> i still happen to think Modules/1.1 is perfectly adequate...i know it's got it's a few little flaws that would be great to fix up, but it works /fine/ :)
[17:13] <Wes-> Modules/1.1 is not adequate in environments where require may not block
[17:13] <Wes-> That is why we have seen require.ensure, require.async, etc evolve
[17:14] <Wes-> Modules/2.0 makes those obsolete for the common use-cases
[17:14] <deanlandolt> yeah, understood...but in combination with a build tool it's adequate
[17:14] <Wes-> and only needed for explict lazy-load of modules, rather than pure dependency resolution
[17:14] <Wes-> No, it's not - your build tool still needs to be told about the dependencies somehow
[17:14] <deanlandolt> Modules/2.0 could fix a lot of things, and i agree it'd be a good direction to pursue...but let's be honest...you and i both know 1.1 /works/
[17:15] <deanlandolt> ah, yes, the dependency scraping /is/ an issue
[17:15] <deanlandolt> not impossible, but it's a wart
[17:15] <Wes-> Yes - but in implementing /1.1 for the browser (several times, BTW) - I have found it to be slightly inadequate, and I *do* use server-side processes
[17:15] <Wes-> "slightly" because it requires caller-based dependency resolution (non-standard) or module scraping (which is smelly, and does not support computed dependencies)
[17:16] <deanlandolt> yep...though, how would /2.0 support computed dependencies?
[17:17] <Wes-> deanlandolt: Can you find my latest message to Christoph Dorn?
[17:17] <Wes-> It shows one way to do them
[17:17] <Wes-> another is
[17:17] <deanlandolt> yeah, i'll look now..still catching up -- been away from the computer all day and i'm way behind :-/
[17:17] <Wes-> module.declare(function() [ isGpsee() ? [ "gpsee" ] : [ "system" ], function() { MODULE } );
[17:18] <Wes-> lol, I know how that goes
[17:18] <Wes-> this has been an ACTIVE week
[17:18] <deanlandolt> oh, okay, that makes sense...kinda nice, really
[17:20] <Wes-> Yep! Computed dependencies, no scraping, works everywhere
[17:20] <Wes-> can support "return exports" without breaking implementations that do not use function-scope
[17:20] <Wes-> allows monkey patching of module/exports because of the wrapper, too
[17:21] <deanlandolt> yeah, that's perhaps the biggest win of all...
[17:22] <deanlandolt> futureproofing (or, as close as is possible)
[17:22] <Wes-> Deps are way bigger than script-tag. That realization is why I changed my mind and am willing bless a /2.0
[17:22] <Wes-> And futureproofing, I thought of that as I was trying to explain how to patch 1.1 to go to 2.0
[17:22] <Wes-> "moment of clarity"
[17:23] <deanlandolt> add it all up and it seems like a win
[17:23] * Wes- nods emphatically
[17:23] <Wes-> take a look at my post to Kevin this morning
[17:24] <deanlandolt> reading it now actually
[22:25] <Wes-> la la laa
[22:53] <Wes-> module.declare(deps, factory)
[22:53] <Wes-> module.declare(factory)
[22:53] <Wes-> what's the best way to detect "no deps"? typeof is not array, or typeof is function?
[22:53] <Wes-> Hmm, there is no array type, I guess that gets easy. ;)

 

 

Logs by date :