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

2010-10-28:

[15:50] <WesMac> deanlandolt1: Hey, I think I just came up with another neat idiom
[15:50] <deanlandolt1> WesMac: what's that?
[15:50] <WesMac> pop the module's dependencies array, as defined by module.declare, on the module's module variable as property deps
[15:51] <WesMac> s/pop/put/.
[15:51] <deanlandolt1> as in?
[15:51] <deanlandolt1> i'd suggested doing that as module.dependencies but it got slapped down because of typing :)
[15:51] <WesMac> Oh, I thought you were talking about my original proposal where using module.dependencies *documented* the dependencies
[15:52] <deanlandolt1> i don't know if it'd be safe to mix it in completely, but i guess you could put it on like an array (module.0 == require(first-dep-listed)
[15:52] <deanlandolt1> no, i was mixing the two together...
[15:52] <WesMac> module.declare(["a", "b"], function(r, e, m) {
[15:52] <deanlandolt1> put it there and even make it mutable
[15:52] <WesMac> var a = module.deps[0];
[15:52] <WesMac> var b = module.deps[1];
[15:52] <WesMac> }
[15:52] <deanlandolt1> aye...yeah, that's what i was suggesting (except i spelled it out completely, which is apparently too painful)
[15:53] <WesMac> Ah, sorry, I didn't catch the subtlety there
[15:53] <deanlandolt1> i also really like module.declare({foo: "a"}, function(r, e, m) { m.deps.foo })
[15:54] <WesMac> deanlandolt1: That's an interesting proposition, actually
[15:54] <deanlandolt1> that would allow you to mix pre-declaration and prefetching w/ scraping all into one
[15:54] <WesMac> Is there a way to compose objects like Array.concat?
[15:54] <WesMac> scraping? Your proposal doesn't require scraping AFAICT
[15:54] <deanlandolt1> yeah, the object-form is nice but destructuring would be nicer :)
[15:55] <deanlandolt1> no, the proposal doesn't require scraping, but allows it
[15:55] <deanlandolt1> i meant to say it allows both idioms to mix with injection
[15:55] <deanlandolt1> the scraping could still be done and made available via the require memo
[15:56] <WesMac> *nod* - I just don't see scraping as part of the spec
[15:56] <WesMac> if the local system wants to support it, great!
[15:56] <deanlandolt1> and no, i don't think there's an Array.concat solution available in the raw :-/
[15:56] <WesMac> same with just-in-time require like we have now on the server
[15:56] <deanlandolt1> yeah, but i think almost /all/ local systems would want to support it...thus, i'd say it's one of those things that should be noted in the spec
[15:56] <WesMac> deanlandolt1: How about
[15:56] <deanlandolt1> (deps array optional)
[15:56] <WesMac> [ "a", "b", {c: "c" ]
[15:56] <WesMac> [ "a", "b", {c: "c"} ]
[15:56] <deanlandolt1> yeah, blocking require makes deps array unnecessary
[15:56] <WesMac> puts c on module.deps.c
[15:57] <deanlandolt1> WesMac++
[15:57] <deanlandolt1> so module.deps[0] and module.deps.c...i like, but it gets confusing here...
[15:57] <deanlandolt1> [ "a", {b: "bbb"}, "c"]
[15:57] <deanlandolt1> err...
[15:58] <deanlandolt1> [ "a", {b: "bbb", c: "ccc"}, "d"]
[15:58] <deanlandolt1> is d m.deps[2] or m.deps[3]?
[15:58] <deanlandolt1> not a big deal (should obviously be 2) but possibly confusing
[15:59] <WesMac> m.deps[3]
[15:59] <WesMac> oh, wait
[15:59] <WesMac> what the hell is that?
[15:59] <WesMac> [ "a", {b: "b"}, {c: "c"}, "d" ]
[15:59] <deanlandolt1> it's what you did, but i moved the object one over
[16:00] <WesMac> module.deps[0] == require("a")
[16:00] <deanlandolt1> you're talking about flattening it out, right? that's a little brittle
[16:00] <WesMac> module.deps[1] == require("b")
[16:00] <WesMac> module.deps.b == require("b")
[16:00] <deanlandolt1> well by default it's m.deps.1.b
[16:00] <deanlandolt1> so you've got to flatten it
[16:01] <WesMac> So all we're doing is changing the declaration of dependency from "a string" to "an object which can label a string"
[16:01] <deanlandolt1> yeah
[16:01] <deanlandolt1> so the object MUST contain one key...that's fine and all, but a little verbose if you're remapping all your deps (not that i care, just something i think someone will complain about :))
[16:02] <WesMac> verbose, yes, two extra chars per label
[16:02] <WesMac> OTOH it's clear
[16:02] <deanlandolt1> indeed
[16:02] <WesMac> and doesn't imply anything other than a label
[16:02] <WesMac> the grouped example suggested multiple interdependencies, load order, etc
[16:02] <deanlandolt1> it's just that people will naturally assume they can do this: {foo: "f", bar: "baaaar"}
[16:03] <deanlandolt1> so maybe you allow that /too/ (e.g. no array necessary)... but ugh
[16:03] <deanlandolt1> hmm, true, if load order matters you've gotta have al ist
[16:30] <WesMac> deanlandolt1: after reflection, I see no reason why we have to limit objects to one dependency
[16:30] <WesMac> deanlandolt1: However, we should not limit the position or number of objects or strings in the array
[16:30] <WesMac> so you could find ALL the dependencies (ignoring their names) like this
[16:31] <WesMac> for each (el in arr) {
[16:31] <deanlandolt1> WARNING, WARNING...mozilla specific code ;)
[16:31] <WesMac> if (typeof el === "string") { print "string"; continue; } )
[16:32] <WesMac> for each(oel in el) {
[16:32] <WesMac> if (el.hasOwnProperty(oel)) print("oel")
[16:32] <WesMac> }
[16:32] <WesMac> or something
[16:32] <WesMac> deanlandolt1: That's not moz-specific, that's ECMA 357
[16:32] <deanlandolt1> only implemented by mozilla :D
[16:32] <WesMac> deanlandolt1: semantics!
[16:32] <deanlandolt1> heh
[16:33] <WesMac> And I bet BEA has an implementation, since they wrote the spec
[16:33] <deanlandolt1> but yeah, i can see how it doesn't really matter if there are one or many...
[16:33] <deanlandolt1> but the positions in the array could be cause for confusion
[16:33] <deanlandolt1> BEA? huh, wow
[16:34] <WesMac> yeah, when I'm in corporate-land, I have been known to describe solutions built on "an application framework running BEA E4X"
[16:35] <WesMac> then I wink at the guys on my side of the table
[16:35] <deanlandolt1> hmm, that's some fancy wording i'll be using in my docs ;)
[16:35] * deanlandolt1 lives in corporate situations :-/
[16:44] <WesMac> sounds a lot better than "we're going to charge you a bundle and deliver javascript" :P
[16:44] <WesMac> CTO-level execs mostly still think of the netscape 4 browser DOM when you say javascript
[16:44] * WesMac sighs
[16:45] <deanlandolt1> indeed...feels like that's changing a little though...slowly
[16:47] <WesMac> Yeah. When we talk turkey I like talk about how our platform uses the dynamic programming language which is benefiting from the most research dollars in multiple corporations (including Apple and Google) while receiving signficant attention from Academia
[16:48] <deanlandolt1> heh, yeah, that's the line i use when talking to pythonistas or rubyists about js
[16:48] <WesMac> Or has the most advanced JIT compilers of any dynamic language
[16:48] * WesMac nods

 

 

Logs by date :