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

2010-10-21:

[0:00] <mikeal> e4x should die in a fire
[0:08] <Wes-> mikeal: the moz hackers would agree with you
[0:09] <Wes-> Hm, implementing my browser-based module system, I can see why returning an alternate exports object is so tempting -- it's trivial in this context
[1:07] <Wes-> man, one or two more weeks like this one and I'm going to lose the use of my arm permanently!
[1:28] <Wes-> Who here has hacked on module systems that pass the test suite?
[10:38] <ondras> Fatal error: Call to undefined method Title::userCanEdit() in /web/commonjs.org/wiki/extensions/SemanticForms/includes/SF_FormEditTab.php on line 32
[10:38] <ondras> hmh
[10:38] <ondras> :)
[14:20] <Wes-> Okay, so, it looks like define() might be a valuable way to specify dependencies, but it doesn't actually solve the script-tag author-format problem unless you can somehow get the URL out of a SCRIPT tag
[14:22] <Wes-> SCRIPT.src looks accessible, but there doesn't seem to be a way to tie it to the javascript functions it created
[14:22] <Wes-> What am I missing?
[15:43] <jbrantly> kriszyp: what do you think about scaling back AMD to just the bare necessities needed for a module to run in both the browser and server?
[15:44] <jbrantly> kriszyp: for example, getting rid of the ID (so just deps and factory), and also possibly getting rid of injects and returns exports?
[15:45] <jbrantly> and things like multiple defines in one script, etc etc
[15:45] <kriszyp> one of the main ideas behind AMD was for unification so we wouldn't need separate specs for transport and authoring (transport/C and transport/D)
[15:47] <jbrantly> khs4473 made (I think) an excellent point that you can essentially split up transport. Use a really scaled back version of define() for direct loading (ie, authoring and transport for development), and then use a regular transport for packaging for production (this is where you would need ID, for example)
[15:48] <kriszyp> and then you have two specs
[15:49] <kriszyp> basically the situation we were originally in with transport/C + transport/D
[15:49] <jbrantly> yes, but I'm trying to find some middle ground here
[15:49] <jbrantly> we have some guys on the server side saying no changes
[15:50] <jbrantly> and then we have guys on the browser side saying lets make a whole bunch of changes
[15:50] <jbrantly> so maybe somewhere in the middle is where we need to be?
[15:51] <jbrantly> hell, even Wes said http://groups.google.com/group/commonjs/msg/8fa00eb6ff2d109e
[15:51] <zumbrunn> that would still be a transport format, in my opinion
[15:52] <kriszyp> I don't know what is being proposed as a change. I don't see any need for a change. Multiple specs and fragmentation doesn't seem desirable to me
[15:52] <kriszyp> and what we have already has numerous implementations
[15:53] <jbrantly> kriszyp: I can't speak for all, of course, but I think one big change being proposed is getting rid of the ID argument and getting rid of allowing multiple defines in a single (module) file
[15:54] <jbrantly> that removes some issues raised around module naming and still allows direct loading in the browser
[16:02] <jbrantly> also, when you say two specs, you're right, but the secondary spec is specific to packaging I think
[16:03] <zumbrunn> jbrantly: the problem is, it would still add boilerplate to modules in environments where no such boilerplate is needed
[16:04] <zumbrunn> boilerplate is acceptable in the context of packaging/transport specs, but not the modules themselves
[16:05] <jbrantly> zumbrunn: I get where you're coming from, and I more or less agree, but I'm trying to prevent community fragmentation
[16:05] <zumbrunn> and even dependency descriptions we probably only need in the context of packaging/transport
[16:05] <zumbrunn> yes, I would like to avoid that, too
[16:06] <zumbrunn> but if some people want to store and maintain code in a transport format, we probably can't keep them from doing that
[16:07] <jbrantly> I think "some" is being underplayed
[16:07] <zumbrunn> so, the real question in my mind is whether we can agree to ratify/bless a transport format, which some people will treat as their primary format
[16:08] <zumbrunn> it would frgament the community into "CommonJS modules" and "Wrapped CommonJS modules"
[16:08] <zumbrunn> which might not be that bad, if that kind of lingo is used
[16:08] <zumbrunn> or it might be
[16:09] <zumbrunn> that's the question
[16:09] <jbrantly> if module loaders can load both natively, then its no so bad
[16:09] <jbrantly> in my mind, the trick is convincing maintainers of module loaders to implement something like this
[16:10] <jbrantly> such as Wes..
[16:10] <jbrantly> and the fewer changes and differences to the current spec the better
[16:11] <zumbrunn> yes, but adding boilerplate is probably already to much to ask
[16:11] <jbrantly> the boilerplate isn't required unless you want to support direct loading into browsers without a build step/server component
[16:11] <zumbrunn> Wes, seems to think he might come around, if the boilerplate provides an additional feature, such as dependency description
[16:11] <zumbrunn> but I'm not so sure myself
[16:12] <zumbrunn> if it is not requires, then you have two formats
[16:12] <zumbrunn> *requires* even
[16:12] <zumbrunn> *required* even
[16:12] <zumbrunn> <g>
[16:13] * WesMac gets to work and starts reading scrollback
[16:14] <jbrantly> zumbrunn: would you ever agree to an ID in the boilerplate?
[16:15] <zumbrunn> as long as the boilerplate is in a transport fromat, I don't really care
[16:15] <zumbrunn> whatever is better technically / feature wise
[16:19] <WesMac> zumbrunn: I'm honestly more interesting in solving module dependency resolution than the script-tag loader goal, but if we can kill two birds with one stone then it is definitely worth considering
[16:20] <WesMac> zumbrunn: Did you have a chance to read my long essay the other day?
[16:20] <zumbrunn> yes
[16:20] <zumbrunn> (I think so)
[16:20] <zumbrunn> and I don't remember disagreeing
[16:21] <WesMac> Right - so on the server end we have the luck to have an optimization which allows our CommonJS Environment to provide all possible modules all the time, so dependency resolution doesn't get talked about much
[16:21] <WesMac> But it is in fact very important
[16:22] <jbrantly> kriszyp: what non-browser implementations of AMD are there except for Node?
[16:23] <kriszyp> well node doesn't implement it (yet anyway), but nodules does (well, I haven't checked in the require.def -> define name change)
[16:24] <kriszyp> and transporter uses (haven't checked in the rename there either) for wrapping commons modules
[16:24] <jbrantly> I meant node as in nodules + your patch :)
[16:24] <kriszyp> ah, ok :)
[16:24] <WesMac> kriszyp: So who all is authoring modules in Transports/D format today?
[16:25] <kriszyp> I don't know of anyone
[16:25] <jbrantly> I had starting implementing it in node last night before deanlandolt mentioned your existing patch. Whoops.
[16:25] <kriszyp> I switched transporter away from transport/D and requirejs users don't use transport/D
[16:26] <jbrantly> I liked Transport/D (*cry*). It was my preferred format for Yabble but I didn't do anything big with it
[16:26] <WesMac> okay, so all these users that we're "alienating" because we use CommonJS modules, who exactly are they?
[16:27] <kriszyp> transport/D was great for avoiding pause/resume from transport/C, but once pause/resume was eliminated it lost some of its advantage (at least in terms of brevity)
[16:31] <jbrantly> cdorn just made a post that pretty much states the middle ground proposal, kriszyp
[16:32] <WesMac> kriszyp: Have you ever tried injecting modules into <IFRAME><SCRIPT></IFRAME> ?
[16:33] <kriszyp> WesMac: no, I haven't. and your questions to the ML would have to be answered by jrburke, I don't know
[16:34] <WesMac> kriszyp: k thx - iframe-script is another way to get another var-object (window) that doesn't involve wrapping, but something keeps nagging me about cross-domain access problems. (I don't spend a lot of time poking around there)
[16:35] <kriszyp> jbrantly: cdorn's suggestions are already a part of AMD. Is the suggestion simply to break AMD into two specs (without actually changing the API at all, just have the parts of the spec defined in two places)?
[16:37] <jbrantly> basically, yes. One for authoring but still loadable in browser (but really stripped down to make more palatable to server folk), and the other for packaging (multiple modules in one file/script -> module ids explicitly specified)
[16:37] <jbrantly> server loaders wouldn't need to implement the packaging spec
[16:38] <jbrantly> and it could kind of be thought of as a traditional transport now
[16:38] <jbrantly> thus the Transport/E that cdorn proposed
[16:39] <WesMac> I think if we're talking about module authoring formats, we're talking about, well, a new modules spec -- not a new transport
[16:39] <WesMac> framing it as a transport is really side-stepping the question and doesn't help anybody in the long run
[16:39] <jbrantly> WesMac: I think you misunderstood
[16:40] <WesMac> OH
[16:40] <WesMac> you're talking about making multiple-modules-per-file a transport?
[16:40] <jbrantly> yes
[16:40] <jbrantly> and leaving that out of the authoring spec
[16:40] <WesMac> If so, what's to prevent this merry-go-round in six months of "we don't want to use a server step to aggregate our modules"?
[16:41] <kriszyp> I still don't get how adding specs and making things more complicated helps. A single simple spec that solves multiple problems is a feature, not a bug. if a server wants to only allow anon modules (no id), or only allow module ids that match the expected id (that's what I do in nodules), that is fine.
[16:41] <WesMac> We should make sure that we have a clear delineation of goals
[16:41] <WesMac> kriszyp: Servers have allowed anonymous modules. We look at the filename. It's there, right in the very core of Modules/1.0 and key to securability
[16:41] <WesMac> kriszyp: Servers have never allowed anonymous modules. We look at the filename. It's there, right in the very core of Modules/1.0 and key to securability
[16:42] <jbrantly> kriszyp: and I don't "get" how a build step is a big deal. I think the point is to try to find some middle ground.
[16:42] <WesMac> I also believe that editing the module source code because you want to put the file in another directory is stupid
[16:43] <jbrantly> WesMac: btw, I don't think anyone is planning on writing prepackaged modules in source form (ie, multiple modules in one file), but I could be wrong. The idea in the new proposal is just to explicitly get rid of that option.
[16:43] <kriszyp> WesMac: absolutely (to the one with "never" in it :) )
[16:47] <jbrantly> kriszyp: are you guys really not willing to budge or ..? As near as I can tell, you're basically saying do it our way. Otherwise, we'll just do our own thing
[16:49] <deanlandolt> jbrantly: i think kriszyp is saying *this is all already possible* and is saying that you can make some stuff optional in the spec
[16:49] <kriszyp> I am just saying I am not convinced by the need for multiple specs. I can say that, right?
[16:49] <WesMac> kriszyp: Sure. I personally believe that there should be only one way to write modules.
[16:50] <deanlandolt> if you make some stuff optional, you have a *base* that says exactly what's required to implement...that's your spec for servers...what's wrong w/ that?
[16:51] <kriszyp> Adding text about the security implications of supporting module ids is reasonable. I thought James already wrote up some, not sure if that made it in yet
[16:52] <jbrantly> deanlandolt: what do you mean exactly by optional? so lets take the id argument that is optional. Right now it's optional to the module author. You're saying also make it optional for the implementation to support it?
[16:52] <jbrantly> if thats the case, I don't see how its any better than two specs personally
[16:52] <kriszyp> cuz you only have to look in one place! :)
[16:52] <deanlandolt> what kriszyp said: "if a server wants to only allow anon modules (no id), or only allow module ids that match the expected id (that's what I do in nodules), that is fine."
[16:52] <WesMac> What is the purpose of the id argument?
[16:53] <WesMac> Any module loader that believes it is not a Secureable Modules implementation
[16:53] <deanlandolt> but parts of the spec are optional, not the id itself being optional
[16:53] <kriszyp> if you have multiple modules in one script, the id indicates the id of each module
[16:54] <WesMac> so you ARE talking about authoring scripts where you have more than one module per file
[16:54] <kriszyp> I wouldn't recommend that
[16:54] <jbrantly> ... but it's possible
[16:54] <kriszyp> sure
[16:54] <deanlandolt> nor would you have to support it (is what i'm trying to argue...but how do we specify that?)
[16:55] <WesMac> deanlandolt: we leave id right out of the spec, that's how
[16:55] <jbrantly> deanlandolt: ok, so you don't have to support it. Then things arent very common anymore
[16:55] <deanlandolt> yeah, the common part is the baseline
[16:55] <kriszyp> if what we are getting is some way of making it clear that servers don't need to support the module id, and authors should be aware of that to maximize portability, that sounds good to me
[16:55] <jbrantly> so then that needs to be extremely well defined I think
[16:56] <jbrantly> kriszyp: exactly
[16:56] <jbrantly> I would probably be onboard with that
[16:56] <kriszyp> cool
[16:56] <deanlandolt> that's what i'm trying to get at, yeah..but as jbrantly it's gotta be extremely well-specified
[16:56] <kriszyp> and if we need a name change, I am fine with that too :)
[16:56] <WesMac> kriszyp: What does this have to do with servers?
[16:57] <kriszyp> WesMac: true, it doesn't need to be limited to servers
[16:57] <jbrantly> btw, what's wrong with Modules/Define for the name?
[16:57] <WesMac> The modules can lie to a browser environment just as easily
[16:57] <kriszyp> right, but if they are in <script> they already can do antyhing they want
[16:58] <WesMac> name for "define" -- I believe I would advocate for require.depends()
[16:58] <kriszyp> well, I meant the name of the spec
[16:58] <WesMac> kriszyp: Yes, if they are in a script - but they don't have to be
[16:58] <WesMac> kriszyp: *common* js
[16:58] <WesMac> Means that modules written one place should work every where
[16:58] <WesMac> the same way
[16:59] <deanlandolt> WesMac: all modules, all possible forms? that seems a little limiting
[17:00] <WesMac> deanlandolt: One module format!
[17:00] <WesMac> One meaning per module declaration!
[17:00] <deanlandolt> no extensions?
[17:00] <WesMac> Sure, embrace extend away
[17:00] <deanlandolt> no defined extensions then
[17:00] <WesMac> But don't specify optional stuff that changes behaviour in the core spec
[17:00] <deanlandolt> gotcha
[17:00] <jbrantly> which, btw, is kinda getting back toward the new proposal
[17:01] <jbrantly> sorta..
[17:01] <deanlandolt> so why not just call AMD 2.0, make the boilerplate optional and call it a day? :)
[17:01] <deanlandolt> err, call AMD Modules 2.0
[17:02] <jbrantly> the idea with the new proposal was that it's very baseline, and then extra stuff added in another spec (as a transport in this case). But I could see two specs with one API
[17:02] <deanlandolt> servers can preprocess the boilerplate away, right? and it's a version bump so no big deal that the servers need to change
[17:02] <jbrantly> baseline: define(deps?, factory)
[17:02] <WesMac> deanlandolt: Modules/2.0 should have more attention given to it than that
[17:02] <jbrantly> extension: define(id?, deps?, factory)
[17:03] <deanlandolt> WesMac: well, yeah...i'm just saying why bother forking the specs at all if we're all really talking about bumping the version
[17:03] <WesMac> jbrantly: The thing about transports - really, they don't technically need specification unless we have multiple vendors attempting to interoperate
[17:03] <WesMac> jbrantly: This is because the core module format defines what executes based on input source code. How it gets from point A to point B is up to the vendor
[17:03] <WesMac> deanlandolt: Because Modules/2.0 would replace Modules/1.1
[17:03] <jbrantly> WesMac: yea, I was advocating getting away from the term anyways. I was saying that was how the new proposal was wording it
[17:04] <kriszyp> it wasn't my intention to propose anything that would force a bump to Modules/2.0
[17:04] <WesMac> kriszyp: Intention or not, that's really what we have. A situation where newly-authored, spec-conforming modules throw execptions when require()d on current CJS environments
[17:05] <deanlandolt> WesMac has a compelling argument
[17:08] <jbrantly> so my question is: if we can agree that there is some baseline, and then some optional extensions (id, injects, etc), one spec with "optional" everywhere or one baseline spec + extension spec(s)?
[17:08] <deanlandolt> jbrantly: that seems right to me but IIUC WesMac begs to differ
[17:09] <deanlandolt> perhaps one baseline spec and then move the interesting parts of AMD into a transports spec
[17:09] <jbrantly> deanlandolt: what seems right? I gave two options :)
[17:09] <deanlandolt> sorry, the first one
[17:09] <deanlandolt> but either actually seem right to me and WesMac disagrees about extensions at all...
[17:10] <jbrantly> I'm ok with either, but if we do the first like, like I said, we should definitely put in language about compatiblity, etc and maybe even give some good examples
[17:10] <deanlandolt> so instead of extensions why not just have a more unified Transports/E that has the extras from AMD
[17:10] <jbrantly> deanlandolt: that is essentially cdorn's proposal
[17:10] <deanlandolt> yeah, i gathered
[17:11] <deanlandolt> just kinda realizing that now
[17:11] <deanlandolt> what i didn't get was whether we could make the boilerplate optional...
[17:11] <jbrantly> I think thats the case
[17:11] <deanlandolt> just because you /can/ author modules that can be loaded in a script tag shouldn't mean you /must/
[17:12] <jbrantly> right
[17:12] <deanlandolt> oh? well good
[17:13] <WesMac> You can't make the boilerplate optional if you want your module to be loadable in a script tag
[17:13] <WesMac> If you want script tags to load commonjs modules, then, the spec must include the boilerplate
[17:13] <WesMac> :. boilerplate is not optional if we want to solve this class of problems
[17:14] <deanlandolt> WesMac: why not? the spec can define and include the boilerplate and say compliant loaders have to support it
[17:14] <WesMac> that said -- it is possible to create a CommonJS environment which could load both MOdules/1.1 and Modules/2.0 modules, for example
[17:14] <deanlandolt> but that doesn't mean modules must be authored with boilerplate, right?
[17:14] <WesMac> deanlandolt: It does indeed! Otherwise we just have Modules/1.1
[17:14] <deanlandolt> i guess i don't understand why a Modules/2.0 couldn't define boilerplate-optional modules
[17:15] <WesMac> Because they wouldn't work everywhere
[17:15] <jbrantly> hmm
[17:15] <jbrantly> he kinda has a point
[17:15] <deanlandolt> but they would...you just wouldn't be able to use the script tag
[17:15] <deanlandolt> the script tag is /optional/
[17:15] <deanlandolt> hmm, crap, now that i think about it...
[17:15] <deanlandolt> yeah, i guess then everyone would just always use the boilerplate
[17:15] <WesMac> Not to put too fine a point on it, but if you make the boilerplate optional, then there is no point to MOdules/2.0
[17:16] <jbrantly> "by default", a non-define module would not be runningable everywhere
[17:16] <deanlandolt> so why not just leave 1.1 and 2.0 in place and allow them to work in harmony
[17:16] <WesMac> exacly
[17:16] <WesMac> exactly to jbrantly
[17:16] <WesMac> deanlandolt: That's certainly an option
[17:16] <WesMac> But just jumping on a spec that's barely implemented anywhere, not well thought about, and apparently has never passed the test suite is not a great way to create modules/2.0
[17:17] <deanlandolt> then, really, nothing would change
[17:17] <WesMac> If we are going to create modules/2.0, some actual thought by a wide segment of the community needs to occurr
[17:17] <deanlandolt> heh...yeah
[17:17] <deanlandolt> i'm not saying we call AMD modules/2.0 yet...but perhaps that's the track it's on
[17:18] <WesMac> If we do Modules/2.0, we should also fix the global-vs-local require spec bug
[17:18] <deanlandolt> maybe call it the ModuleScript spec
[17:18] <WesMac> and maybe some other subtle issues
[17:18] <jbrantly> btw, based on this, I'm starting to lean more towards a baseline spec + extensions
[17:18] <WesMac> I disagree
[17:18] <WesMac> "ModuleScript" - why not just call it RequireJS
[17:18] <deanlandolt> :)
[17:18] <jbrantly> right
[17:18] <WesMac> There's no point in coming up with a spec that only works some places
[17:19] <dmachi> I have a question regarding 'voting' for the various proposals. Is this process documented somewhere (as in who gets to vote and such)?
[17:19] <WesMac> dmachi: have you ever been in the second grade?
[17:19] <jbrantly> the process is that WesMac gets 10000 votes
[17:19] <deanlandolt> why? how is it going to work in /all/ places if it's not a standard yet :)
[17:19] <WesMac> It's pretty much like that
[17:19] <WesMac> jbrantly: LOL ;
[17:19] <deanlandolt> :D
[17:19] <WesMac> deanlandolt: standards, standards-track
[17:20] <deanlandolt> dmachi: i don't think voting really means anything -- it's just a /everybody show their hands/ to get an acid-test for consensus
[17:20] <deanlandolt> so, track RequireJS/AMD for Modules/2.0 and let's all move on w/ our lives :)
[17:20] <dmachi> WesMac: I understand how to vote yes, i just meant is there some group of people that get to vote and others that don't?
[17:20] <WesMac> dmachi: no, there isn't
[17:20] <dmachi> deanlandolt: ok, just curious about that since it gets mentioned occasionally.
[17:21] <dmachi> WesMac: thanks.
[17:21] <deanlandolt> dmachi: yeah, just a show of hands
[17:21] <jbrantly> ok, so from where I stand. Modules/2.0 (define is required, arguments are deps?, factory) Then Modules/2.0/Extensions or something for specifying id, injects, return exports, etc?
[17:21] <WesMac> deanlandolt: If something like AMD winds up being the basis for Modules/2.0, we need to do a lot more than "get on" with things
[17:21] <deanlandolt> obviously non-binding...it's not like there's a charter and rules and stuff...just norms that have evolved
[17:21] <WesMac> We need to engage some brains, write some implementations, run some tests
[17:22] <deanlandolt> WesMac: what i mean is we can just labor under the impression that there /will/ be a breaking change in the modules spec eventually (we already assumed that or we wouldn't have versioned it)
[17:22] <WesMac> jbrantly: If you add an extension to specify the id, you are no longer in SecureableModules territory
[17:22] <WesMac> Maybe we could have a group InsecureModules extensions in parallel to the modules spec
[17:22] <jbrantly> WesMac: see all of the arguments above
[17:22] <jbrantly> WesMac: ie, loaders can choose to ignore it for example
[17:23] <deanlandolt> WesMac: the loader doesn't have to respect the supplied id (e.g. what kriszyp does w/ nodules)
[17:23] <WesMac> jbrantly: If it's ignorable, then what is the point?
[17:23] <jbrantly> WesMac: basically eases packaging
[17:23] <deanlandolt> it's useful for packaging/transport...
[17:23] <deanlandolt> that's all
[17:23] <WesMac> why not just put it comments?
[17:23] <WesMac> If it's useful for transports, then it is part of the transport
[17:23] <deanlandolt> and what, run narcissus on it? :)
[17:24] <deanlandolt> WesMac: yeah, i think everyone agrees on that point
[17:24] <deanlandolt> but there should be some harmony
[17:24] <jbrantly> WesMac: It's totally optional though
[17:25] <WesMac> jbrantly: Is it used outside transports?
[17:25] <jbrantly> WesMac: it could be
[17:25] <WesMac> To what end?
[17:25] <deanlandolt> but it probably ought not be respected
[17:25] <jbrantly> WesMac: not saying it should be.
[17:25] <deanlandolt> the end is a a harmonized fn signature for define
[17:25] <jbrantly> ok ok
[17:25] <jbrantly> how about this
[17:25] <jbrantly> it's a "transport"
[17:26] <jbrantly> but uses the same API (define) as an additional argument
[17:26] <jbrantly> I mean if all it is is classification of spec...
[17:26] <deanlandolt> yeah, something like that
[17:26] <WesMac> then we can keep it out of hte module authoring spec
[17:26] <WesMac> and anybody writing modules to the module authoring spec can expect them to work the same everywhere
[17:26] <jbrantly> hmm
[17:27] <deanlandolt> WesMac: and as noted that's perfectly viable everywhere..so why not
[17:27] <jbrantly> I *think* that might be ok
[17:27] <jbrantly> btw
[17:27] <jbrantly> so far totally in line with cdorn's proposal
[17:27] <jbrantly> with different names
[17:27] <WesMac> deanlandolt: If you put it in the module authoring spec, and people use it, and their transport HAPPENS to use it, then they see one thing. And then when they write their code on a platform which uses a different transport, the behaviour of the code changes.
[17:28] <WesMac> That is not a good module format. Uniform behaviour is very important.
[17:28] <deanlandolt> that's very true...so don't put it in...okay, i'm on board with that
[17:28] <jbrantly> kriszyp: you following any of this?
[17:29] <deanlandolt> so we're talking about /three/ distinct things...Modules (1.1), Scripts (possibly, maybe, perhaps someday Modules 2.0) and Transports
[17:29] <jbrantly> and optional extensions to scripts
[17:29] <deanlandolt> jbrantly: to what ends? that's what Transports is for...
[17:29] <deanlandolt> servers can chose to support Transports
[17:29] <deanlandolt> (or you can chose to use a loader that does, like nodules)
[17:29] <jbrantly> injects and returns exports are two biggies
[17:29] <jbrantly> and that is authoring
[17:30] <jbrantly> not transport
[17:30] <deanlandolt> oh, i'd say that should be in Scripts off the bat
[17:30] <jbrantly> but they should not be part of the baseline
[17:30] <WesMac> jbrantly: You are right about injects and returns being authoring concerns
[17:31] <deanlandolt> the notion that scripts has to be perfectly translatable to 1.1 seems unnecessary to me
[17:31] <WesMac> What does injects do again?
[17:31] <WesMac> deanlandolt: Agreed.
[17:31] <WesMac> But 1.1 modules should be runnable on 2.0 with only the addition of the function wrapping boilerplate
[17:31] <deanlandolt> exactly
[17:32] <WesMac> and pass the test suite! :)
[17:32] <deanlandolt> upward compat, not backward, is what we need
[17:32] <deanlandolt> if you're gonna have to write code to support it anyway, what's the point
[17:32] <jbrantly> WesMac: are you ok with injects, returns exports going into the Scripts spec but with big fat "implementation optional" tags on them?
[17:33] <deanlandolt> jbrantly: isn't that always true :)
[17:33] <WesMac> jbrantly: I think if we are defining Modules/2.0 that the door is open to injects and return exports as *non optional* even -- but that further study is needed
[17:34] <jbrantly> WesMac: ok
[17:34] <jbrantly> so for proposal status, keep them in
[17:34] <deanlandolt> if you don't implement them, big deal -- you don't have a fully compliant loader...oh well
[17:34] <WesMac> As separate paragraphs that are mutally separable from the main spec as time goes on
[17:35] <WesMac> I think closure-based dependency annotation should be non-separable
[17:35] <WesMac> I'm also torn between dependency-annotation actually meaning dependency-declaration
[17:36] <jbrantly> I wish kriszyp were here
[17:36] <jbrantly> so we can get some kind of tentative agreement
[17:37] <jbrantly> I think the end result is nothing changes for him except the global variable part?
[17:37] <WesMac> can you guys open your email to chris dorn's email from 13:36 Eastern?
[17:37] <WesMac> where he says, "can you explain the problem based on this:"
[17:37] <WesMac> won't that throw?
[17:38] <WesMac> because oh
[17:38] <WesMac> oh no, it won't, because require() doesn't execute until after module.define() completes
[17:38] <deanlandolt> exactly
[17:39] <WesMac> yeah, brain fart for a minute
[17:39] <WesMac> That was the problem with module.dependencies
[17:39] <jbrantly> btw, do we want module.define or just "define"?
[17:40] <WesMac> Although I DO have a rigorous scraping algorithm for that
[17:40] <WesMac> jbrantly: I won't argue heavily, but I think there is no reason to add another global symbol
[17:40] <deanlandolt> jbrantly: cdorn claims they're two things...one for scripts (module.define) and one for transports (define)
[17:40] <WesMac> Especially because it enforces a particular implementation
[17:40] <deanlandolt> and they could have two distinct signatures (maybe we shouldn't call them both define)
[17:40] <WesMac> If you have module.define, each module can have it's own define function if that is good for the environment
[17:40] <WesMac> with plain define, it's a global symbol
[17:41] <deanlandolt> or, perhaps he hasn't argued that they should have distinct signatures, but i think WesMac has made a good case for it
[17:41] <jbrantly> WesMac: plane define would be a free variable
[17:41] <jbrantly> *plain
[17:41] <jbrantly> *could
[17:41] <WesMac> Right, which means you only have one, the global, and can't implement multiples, like current implementations of require
[17:41] <jbrantly> no
[17:42] <jbrantly> I think most implementations of require have a separate function per module
[17:42] <deanlandolt> why must it be global?
[17:42] <jbrantly> you could do the same exact thing with define
[17:42] <WesMac> right, and pass it in. But why?
[17:42] <WesMac> Can you justify another symbol?
[17:42] <jbrantly> eh
[17:43] <jbrantly> 6 one way, half-dozen the other
[17:43] <WesMac> no, scope pollution is a serious issue, and we're setting up patterns for future revisions down the road
[17:43] <jbrantly> but it's a big strange for the browser environment
[17:43] <WesMac> strange to use objects as namespaces?
[17:44] <jbrantly> var module = {define: {}}
[17:44] <jbrantly> no
[17:44] <jbrantly> ok, I take it back
[17:44] <jbrantly> :)
[17:44] <WesMac> :)
[17:44] <jbrantly> I would say then that Transport/E should not be "define"
[17:44] <jbrantly> I think we should use the same
[17:44] <WesMac> I think it should be require.depend()
[17:44] <deanlandolt> module.define wouldn't have to be global...but transport/e would, yeah
[17:45] <WesMac> Because it document's dependencies of the module before require can be called
[17:45] <deanlandolt> require.exec([], function() {})
[17:45] <jbrantly> I don't like exec
[17:45] <deanlandolt> eh, yeah, it's ugly
[17:45] <jbrantly> it implies the factory will be executed
[17:45] <WesMac> and overloaded
[17:45] <jbrantly> when its actually not
[17:46] <jbrantly> WesMac: yes, it does document dependencies, but it also does other things. I think define is general enough to cover all cases
[17:46] <WesMac> require.provide(["x", "y"]).then(function() {} )
[17:46] <deanlandolt> heh
[17:47] <deanlandolt> that would make require.provide a promise (according to promises/a at least)
[17:47] <deanlandolt> which would allow you to require("promise").when(require.provide(["x", "y"], function() {}, function(e) {})
[17:47] <jbrantly> let's keep it simple, eh?
[17:47] <jbrantly> module.define() :)
[17:48] <WesMac> I'm not up on promises as much as I should, but the above is simple
[17:48] <deanlandolt> WesMac: yeah, that's all a promise is...an object with a then function
[17:48] <deanlandolt> (in promises/a at least)
[17:48] <WesMac> function provide(depList) { resolveDeps(depList); return function(a) { a() } }
[17:48] <WesMac> no?
[17:49] <deanlandolt> that's nice
[17:49] <WesMac> oh, that's not quite right though
[17:49] <WesMac> function provide(depList) { resolveDeps(depList); return { then: function(a) { a() } } }
[17:49] <deanlandolt> yeah, that one
[17:49] <deanlandolt> that returns a promise
[17:50] <jbrantly> that executes it tho
[17:50] <deanlandolt> (you don't have to call it that if you don't want, of course, but it's a ducktyped promise :))
[17:50] <deanlandolt> jbrantly: no, you have to call then w/ a fn to execute...is that not right?
[17:51] <jbrantly> function(a) { a() }
[17:51] <jbrantly> .then(function() {});
[17:51] <deanlandolt> yeah, but look at the second one
[17:51] <jbrantly> { then: function(a) { a() } }
[17:51] <deanlandolt> jbrantly: what's wrong w/ that?
[17:51] <jbrantly> .then(function() {});
[17:51] <deanlandolt> is it not supposed to execute?
[17:52] <jbrantly> not if the dependencies havent been resolved
[17:52] <deanlandolt> you can .then(function() {}) all you want, no big deal
[17:52] <jbrantly> which happens async
[17:52] <deanlandolt> oh, right...that's why you need a real promise :)
[17:52] <deanlandolt> require("promise").defer;
[17:52] <jbrantly> I wouldn't throw promises into the mix
[17:52] <deanlandolt> yeah, i know
[17:52] <deanlandolt> that's really marginalize the discussion...just sayin
[17:53] <jbrantly> then we'd have a whole other debate
[17:53] <deanlandolt> it's /almost/ a promise
[17:53] <WesMac> shit
[17:53] <WesMac> you're right
[17:53] <WesMac> You need sync-mode module loading to make that ^^^^^^^ work properly
[17:53] <jbrantly> correct
[17:53] <WesMac> glad you caught that before I proposed it
[17:53] <jbrantly> :)
[17:53] <jbrantly> thats what I'm here for
[17:54] <jbrantly> to catch your mistakens
[17:54] <jbrantly> *mistakes
[17:54] <WesMac> :)
[17:54] <jbrantly> module.dependencies =..., etc :P
[17:54] <jbrantly> ok
[17:54] <WesMac> Hey at least I am throwing out ideas instead of digging in my heels! :)
[17:54] <deanlandolt> WesMac: no doubt
[17:54] <jbrantly> I'm proud of you (no really, I am)
[17:55] <jbrantly> I think we might actually be able to come up with a viable solution to this mess
[17:55] <WesMac> thanks. :)
[17:56] <jbrantly> ok, so who wants to write this up? :)
[17:56] <WesMac> I don't mean to come off as a naysayer, but I really, really, really feel strongly about things like backwards/forward compatibilty, community fracturing, and the historical view 2 years from now. I don't want CommonJS to be a group which breaks everything every time we get 5 new subscribers to the mailing list.
[17:56] <WesMac> I can't right now, all this extra typing this week is killing me
[17:56] <WesMac> seriously, I can't feel my right arm below my elbow
[17:57] <deanlandolt> jbrantly: i'll do it...what exactly did we decide though? that module.define is acceptable for scripts?
[17:57] <jbrantly> yea, I hear you. Frankly, and not to be a jerk or anything, but I'm rather pissed at how RequireJS approached this, but eh. It is what it is, and it worked I guess.
[17:57] <WesMac> deanlandolt: Would like the opportunity to review/edit :)
[17:57] <deanlandolt> WesMac: that's awful man
[17:57] <jbrantly> deanlandolt: I personally think so, yes
[17:57] <deanlandolt> WesMac: sure -- especially since i'm a little slow on these matters...and don't even have a horse in the race :)
[17:58] <WesMac> deanlandolt: It's life. I should get my ass back to physio, athough, I've had to lay of the piano again *sniff*
[17:58] <WesMac> deanlandolt: Makes you a good author
[17:58] <deanlandolt> heh...i bet it keeps you succinct
[17:59] <WesMac> succint? me?
[17:59] <WesMac> that's why my arm hurts, lol
[17:59] <jbrantly> alright, lunchtime. Later
[17:59] <deanlandolt> heh :)
[17:59] <WesMac> deanlandolt: so, let's see
[17:59] <WesMac> module.define([ deps ], function (r, e, m ) { MODULE/1.1 module })
[17:59] <deanlandolt> i'm writing it up as questions for cdorn...what i have so far:
[18:00] <WesMac> no change in MODULE/1.1 semantics
[18:00] <deanlandolt> ah, yes
[18:00] <deanlandolt> did we say that? no return exports?
[18:00] <WesMac> need to be able to pass the test suite with a sample impl before stamping
[18:00] <deanlandolt> i thought you said it doesn't make sense to require backward compat
[18:00] <WesMac> Sorry, you could put something other than a 1.1 module in there
[18:00] <WesMac> but if you put a 1.1 module in there, it shoudl work the same as on 1.1
[18:01] <WesMac> (did that make sense)
[18:01] <deanlandolt> yes
[18:01] <WesMac> So, then, we can open the door to discuss return exports
[18:01] <WesMac> and injections
[18:01] <WesMac> as possible other additions to modules/2.0
[18:01] <deanlandolt> yeah, i guess we're proposing that Scripts be a possible 2.0 candidate...if the market takes to it
[18:02] <deanlandolt> (obviously w/ other refinements and discussions before it were to ever get that kind of stamp)
[18:02] <WesMac> I wouldn't "recognize" any specs other than 1.1 in the proposed standards-track 2.0
[18:02] <WesMac> too much bagage and inference
[18:02] <deanlandolt> true
[18:02] <WesMac> need to discuss the problems we are solving and solutions
[18:03] <deanlandolt> i still want to note your point about this being an alternate module authoring format...thus, a possible 2.0
[18:03] <WesMac> problems: express dependencies, mandate closure-wrapping so that script-tag loading can work
[18:03] <WesMac> Call it a "Proposal for MOdules/2
[18:03] <WesMac> Call it a "Proposal for Modules/2.0"
[18:04] <WesMac> and explicitly note in the intro paragraph that it would be the preferred module authoring format for all CJS environments
[18:04] <WesMac> but that it would be allowable for CJS environments to load modules/1.1 modules if they so desired
[18:04] <WesMac> then CJS vendors can advertise "2.0 compatible", "1.1 compatible" or "2.0 and 1.1 compatible"
[18:05] <WesMac> Those have very clear meanings to users: "2.0 is what new code should be"
[18:05] <WesMac> does "module.declare" make more sense then module.define?
[18:06] <deanlandolt> i don't know if an email called "Proposal for Modules/2.0" would go over well...but that's what Scripts is
[18:06] <WesMac> I think it does, since it's what the statement does
[18:06] <WesMac> deanlandolt: get some endorsements before posting
[18:06] <deanlandolt> i don't know...but i /do/ know that define and module.define have two distinct signatures (or should, because the id is senseless in module.define)
[18:06] <deanlandolt> so a different name would be good
[18:07] <WesMac> Being wishy-washy about the intention of a proposal is how we got into this hell hole in the first place
[18:07] <deanlandolt> good point
[18:07] <WesMac> if RequireJS hadn't tried to sneak in a module spec as a transport format, ROLAIDS wouldn't be up 22 cents on the NYSE
[18:07] <deanlandolt> :D
[18:19] <WesMac> deanlandolt: require-repair should also be on the /2.0 list
[18:19] <WesMac> deanlandolt: I think it should be the non-global variable krisk discussed this am
[18:22] <WesMac> module.id and require(module.id) should possibly be put back on the table for debate as well
[18:22] <WesMac> unless that was already settled
[18:35] <WesMac> deanlandolt: my latest post to cdorn has text in it you may want to scoop
[18:37] <deanlandolt> WesMac: sorry, just got pulled away...back to drafting now
[18:38] <deanlandolt> WesMac: i like module.declare...nice
[18:39] <WesMac> thanks! :)
[18:42] <jbrantly> deanlandolt: for what it's worth, I also agree with Modules/2.0. Wes has convinced me
[18:44] <WesMac> deanlandolt: Irakli, Tom Robinson, Chris Zumbrunn, Christoph Dorn, me, Kris Kowal, Kris Zyp, JBrantly, rhs4473, Kevin Dangoor, Stefaan, Ondras, Hannes, Kris Kowal, Ihab Awad, Mark Miller, Kris Zyp, James Burke, Ash Berlin, Mikeal Rogers, Ryan Dahl
[18:44] <WesMac> deanlandolt: ^^^ List that should probably have an opportunity to console before publishing
[18:45] <deanlandolt> isn't that what the list is for?
[18:45] <WesMac> deanlandolt: And maybe ask if they would bless the paper as a starting point for coming up with modules/2.0
[18:45] <deanlandolt> i'm certainly not publishing any module specs...just writing something up that breaks it down (based on your points, and what cdorn put out there)
[18:46] <WesMac> deanlandolt: I'd back-channel the first set of revs to avoid political problems
[18:46] <deanlandolt> dude...if we're writing modules/2.0...umm...i'm not the man for that :D
[18:46] <WesMac> Ah, c'mon, you can do the draft at least :)
[18:46] <deanlandolt> i really have such a shallow grasp of this
[18:46] <deanlandolt> yeah, i can draft something up...
[18:46] <deanlandolt> but mainly just the arguments for why what we're talking about _is_ 2.0
[18:46] <deanlandolt> and the problems we are trying to solve
[18:47] <deanlandolt> everything else would just be me bikeshedding names
[18:47] <deanlandolt> what i'm focused on is pointing out to cdorn and krisk that this is *not* CommonJS/Scripts -- that Scripts is a complete misnomer
[18:49] <jbrantly> I have to go back I'll check back in this evening to catch up on stuff. Take care.
[18:49] <jbrantly> s/go back/go but
[18:49] <deanlandolt> thanks jbrantly
[18:50] <WesMac> Why is it 2.0 - it's a breaking change and we need to signal that to the community
[18:51] <deanlandolt> yeah, but they're gonna suggest that it's not because it's not a Modules format
[18:51] <deanlandolt> but are we just going to redefine the definition of "module"?
[18:51] <WesMac> And since we're doing a breaking change, we should fix some other small gotchas
[18:51] <WesMac> It *IS* a modules format
[18:51] <deanlandolt> there's no doubt about it...there's no way around it
[18:52] <deanlandolt> so let's call a spade a spade and start talking about 2.0
[18:52] <WesMac> right!
[18:52] <deanlandolt> or just put a shovel in this thing and let the rift simmer a little longer
[18:52] <deanlandolt> either way, i'm good
[18:52] <WesMac> I think we should bite the bullet
[18:53] <WesMac> This gives RequireJS a palatable interm solution, they can claim that they support 2.0-standards track or whatever
[18:54] <deanlandolt> yeah...which is reasonable...and i'll go on coding in 1.0 until there's broad support for 2.0 (which should actually be easy enough to shim in w/ your own require fn a la nodules)
[18:54] <deanlandolt> err, 1.1
[18:55] <WesMac> Right, we do 2.0 properly, with the versioning the community gets the right message, everybody is happy
[18:55] <WesMac> doing 2.0 properly means *everybody wins*
[18:55] <WesMac> except users stuck on 1.1 platforms
[18:55] <WesMac> but that's what the branding is all about
[18:55] <WesMac> it makes platforms likely to upgrade
[18:56] <deanlandolt> users on 1.1 platforms have an easy migration path
[18:56] <deanlandolt> they can use something like nodules as a shim
[18:56] <WesMac> Yeah, you don't even need that, I don't think
[18:56] <WesMac> Or, maybe you do
[18:56] * WesMac thinks
[18:56] <deanlandolt> you'd need your own require impl
[18:57] <WesMac> actually, what you need is to expose the module factory
[18:57] <WesMac> ModuleObject.prototype.declare = function(deps, module) { module(); }
[18:58] <deanlandolt> yeah, but if you provide your own require you provide your own module factory
[18:58] <deanlandolt> right?
[18:58] <WesMac> right, but implementing your own require means there's no point in using your environment
[18:58] <WesMac> for example, you can't implement GPSEE's require in JS, because we load C modules
[18:59] <WesMac> without C modules, there is no I/O, database access, etc
[18:59] <deanlandolt> ah, right...but you could provide that to be overloaded somehow
[18:59] <WesMac> True
[18:59] <deanlandolt> too late to spec that
[18:59] <WesMac> Object.prototype.declare = function(deps, module) { module(); }
[18:59] <WesMac> OTOH that will work many places ^^^
[18:59] <WesMac> but you'd have to be careful
[19:00] <deanlandolt> well yeah :D
[19:00] <WesMac> at least make it non-enumerable in an ES5 environment
[19:00] <deanlandolt> don't you have to fill out the args for that module call?
[19:01] <WesMac> actually, you don't
[19:01] <WesMac> it's on the scope chain
[19:02] <deanlandolt> oh...nice
[19:02] <WesMac> but, if it makes you feel better, I just forgot to type it out :)
[19:02] <deanlandolt> :D
[20:15] <WesMac> deanlandolt: Idea for Modules/2.0 --- let's add ModuleObject and ExportsObject classes
[20:16] <WesMac> deanlandolt: Then 2.0.x changes can be shimmed more easily by users without platform-author assistance
[20:16] <deanlandolt> how? as globals?
[20:16] <WesMac> deanlandolt: *hmm*
[20:16] <deanlandolt> on the scope chain?
[20:16] <WesMac> I know!!!
[20:16] <WesMac> we don't define their names
[20:16] <WesMac> but we have module.prototype and exports.prototype
[20:17] <deanlandolt> what are the securability concerns there? or are there any?
[20:17] <WesMac> deanlandolt: That's a really good questino
[20:17] <WesMac> I bet there are some
[20:17] <deanlandolt> still, it's a worthy goal...you should be able to give a module all the tools it needs to bootstrap itself, but nomore
[20:17] <deanlandolt> no more
[20:17] <WesMac> Although I'm not sure if they matter if the important bits are permanent, read-only properties
[20:18] <WesMac> No
[20:18] <WesMac> there's no securability problem
[20:18] <WesMac> because if there was, the same problems would be exposed by Object.prototype
[20:18] <WesMac> So, if we have all module-objects and exports-objects descended from common prototypes via their factory functions
[20:19] <deanlandolt> ah...right
[20:19] <WesMac> then implementations would have a formal way to forward-rev-shim themselves to support slightly newer specs
[20:19] <deanlandolt> that'd be slick
[20:20] <WesMac> yeah, like, it would totally make it easy to add, say, module.resources
[20:20] <WesMac> you add it to your "local" module.prototype, and suddenly all modules have access to it
[23:17] <jbrantly> deanlandolt: ping
[23:19] <jbrantly> deanlandolt: were you actually planning on writing up a draft of Modules/2.0?
[23:19] <jbrantly> if not, I may have some time tomorrow

 

 

Logs by date :