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

2010-04-26:

[2:05] * jhuni has been convinced require is not only not-bad, it is also good if it is given a helping hand from ensure and/or metadata (I would use it personally with ensure)
[2:38] <Dantman> ^_^ and then there's monadic require
[2:39] <Dantman> Hmmmmm, waitasec... rotfl, I think my old plan for banana packages were actually somewhat similar to monadic require...
[2:40] <Dantman> You declared dependency on other packages inside the banana.json, and used banana("packagename") inside a script... but it would throw if you try to include something that you didn't declare dependency on... ^_^ the only difference was it was declared in package metadata instead of ensure.
[2:41] <Dantman> Course the banana idea altogether was a bit of a flop.
[2:43] <Dantman> Wait, what did I do about exporting things again?
[2:50] <kriskowal> Dantman sproutcore's tiki works something like that. I think it's worth pursuing package bundling and async package loading.
[2:50] <kriskowal> dangoor said as much i think, recently.
[2:50] <Dantman> ^_^ banana's flops were in a separate area
[2:51] <Dantman> btw, I didn't have the concept of a "module"
[2:57] <kriskowal> yeah, i recall.
[5:50] <tlrobinson> mikeal: i don't understand the logic here: "In the case of all the IO standards I think it's safe to say that any standard that is sufficiently complex to handle all the issues we've talked about between implementations will usually be hidden behind a friendly implementation specific interface. So why bother with sync/async, why not just make the entire thing async and the sync implementations can just block before calling the callback?"
[5:50] <tlrobinson> are you saying platforms will have their own IO layer on top of CommonJS's APIs?
[5:51] <tlrobinson> that seems backwards to me... why bother with a standard at all if everyone ends up having a different API at the end of the day
[5:58] <Dantman> I think he's aluding to our level 0 vs level 1 idea... undoubtably people are going to make different level 1 impls, but those are done in js and can be required by anyone.
[7:20] <kuya_> ive also wondered why everything coded as async but used as sync where needed
[7:20] <kuya_> ugh too early
[7:20] <kuya_> ive also wondered why everything cant be coded as async but used as sync where needed
[7:47] <ondras> jhuni: in my opinion, function which returns various things is like shooting yourself to leg. By allowing exporting non-exports, we are allowing/recommending shooting yourself to leg, which is not nice
[7:52] <jhuni> ondras: I like my legs... leg (less then, equal, greater than) is a fine operator
[7:52] <jhuni> ondras: whats wrong with exporting non-object types exactly?
[7:56] <jhuni> ondras: what I am mostly interested in is returning functions and functions with prototypes, and I don't see how that is a bad thing in any way
[8:02] <ondras> jhuni: actually, the case with returned value has no relation to modules/require
[8:03] <ondras> jhuni: but once there is an agreement (there is no such agreement now) that a sane non-shooter function returns a constant data type, one cannot export arbitrary data types
[8:03] <ondras> but exporting function with prototype is perfectly possible - exports.MyClass = MyClass;
[8:05] <jhuni> require doesn't return myclass though, there could be other uses for it as well and I haven't heard a very good reason why it should be restricted to object
[8:05] <ondras> wow, my irssi nickcolor suddenly recolored you from yellow to red :))
[8:07] <ondras> hm, "restricted to object", more exact formulation would be "restricted to something"
[8:07] <ondras> actually, I dont give a damn about what is the returned type, as long as it remains constant
[8:08] <jhuni> what do you mean by "remains constant" ?
[8:08] <ashb> kuya_: i've kinda been wondering that too
[8:08] <ondras> typeof(require(id)) == constant
[8:09] <ondras> for every ID string, the value returned by require has the same type
[8:09] <ondras> e.g. the type is not determined by ID
[8:10] <kuya_> ashb: including require? :]
[8:10] <jhuni> ondras: perhaps it can be arranged that typeof(require(id)) === constant
[8:11] <jhuni> ondras: anyways I am busy now, k =/
[8:21] <ashb> kuya_: of course you can't do the 'async transparently' in a browser (as the only way i can think of doing it is by pumping the event loop, which you can't do in a browser)
[8:22] <kuya_> no it comes down to that require(deps, function modulebody() { ... }) again
[8:26] <Dantman> Is that yet a fourth meaning for two arg require?
[8:27] <kuya_> im just sprouting pseudo :)
[8:27] <Dantman> heh ^_^ require's nonexistant second arg has been abused by plenty others already
[8:30] <ashb> Dantman: it all depends wether or not you are willign to chagne behaviour based on what type of objects you pass to functions
[8:34] <Dantman> ;) in any case we've got four conflicting potential meanings for two arg require now... any proposal wanting to use two arg require better prepare to clash with other's wanting a different meaning... heh
[8:37] * kuya_ points out that his code was meant for a module declaration and its just too early in the morning
[8:38] <Dantman> ^_^ I know, but that's a completely new one, hence four...
[8:38] <kuya_> require.def({opts}, function modulebody() {...})
[8:39] <Dantman> require(id, version); require(id, pkgname); require(id, asynccallback); require(id, modulebody);
[8:40] <ashb> i think 1 and 2 should be combined into a url scheme
[8:40] <ashb> but kris k was like 'no we sholdn't invent url schemes' to which i say 'why the fuck not' ;)
[8:44] <kuya_> he does make you swear doesnt he? ;)
[8:46] <Dantman> "pesudo-wgs, natures natural roman Colosseum"
[8:46] <ashb> yeah krisk and I have heated arguments a lot, but i can almost always understand his PoV at least
[9:16] <Dantman> Wes-, didn't the setExports proposal cause issues with your ability to do gcable modules at least in any module that uses it?
[9:16] <Dantman> iirc you had to augment the exports object with some special native stuff or something to get that to work right.
[16:47] <aristid> Wes-: no need to mark encodings sync
[16:59] <kriszyp> cadorn: so just to be clear, is it double parent path (../../my-module) that you were fixing in transporter? It seems that single parent path (../my-module) works fine
[17:00] <cadorn> kriszyp: yeah
[17:00] <cadorn> probably not the best way of doing it but i works :)
[17:01] <cadorn> feel free to optimixe
[17:01] <kriszyp> if it works, that's fine
[17:01] <kriszyp> just wanted to make sure I knew what it was fixing :P
[17:12] <jbrantly> ML was booming yesterday. Yeesh.
[17:17] <kuya_> :)
[17:24] <kriszyp> anyway, thanks for the patch, cadorn
[17:27] <cadorn> kriszyp: np, I think the mappings you are proposing are a good idea for one-arg require and they fit well with browser loading - I think I can layer two arg require on top without needing to complicate transporter and requirejs - that would be really cool
[17:27] <kriszyp> great
[23:45] <hammerdr> has anyone here seen/heard of a Cucumber implementation on JS or CommonJS?

 

 

Logs by date :