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

2009-11-10:

[14:20] <voodootikigod> morning
[20:44] <ashb> deanlandolt: the .then method?
[20:46] <Wes-> what is the .then method?
[20:46] <deanlandolt> yeah, zest doesn't have to worry about that
[20:46] <ashb> i dont know - thats why i was asking about it
[20:46] <deanlandolt> it's hwo to ducktype on a promise
[20:46] <Wes-> Oh, right
[20:46] <deanlandolt> sorry -- should have been more explicit
[20:46] <ashb> oh .its a promise if it has a .then method type thing?
[20:46] <deanlandolt> yeah, if response.then is a function
[20:46] <Wes-> was afraid we were duplicating work, hdon has been experimenting with generator pipelines in gpsee
[20:47] <deanlandolt> Wes-: what would that look like?
[20:47] <Wes-> deanlandolt: Simplistically:
[20:47] <ashb> yield x;
[20:47] <deanlandolt> ashb: yeah, i know how generators work in python
[20:48] <ashb> deanlandolt: the same basically then
[20:48] <deanlandolt> (and assume they work the same in mozilla js)
[20:48] <Wes-> for (line in exec("cat /etc/passwd").exec("sed s/w/X/")) { print(line) };
[20:48] <ashb> x = function() { print(1); yeild y; };
[20:48] <ashb> gen = x();
[20:49] <Wes-> not just generators, though
[20:49] <Wes-> generator *pipelines*
[20:49] <Wes-> so each function is a consumer and a yielder
[20:49] <Wes-> and we have grafted in the ability to use ~p2open as an element in said pipeline
[20:49] <Wes-> thereby giving us functionality similar to | in shell
[20:49] <ashb> in my example, the print doesn't happen until the first time you call gen.next()
[20:50] <ashb> deanlandolt: but w could make hte body (optionally) be a Generator
[20:51] <Wes-> I totally think generators are awesome
[20:51] <Wes-> although I did have a funny problem with them in a real-world app
[20:51] <Wes-> I write a file stream that acted as a generator
[20:51] <Wes-> and I wanted to use it to parse e-mail messages
[20:51] <Wes-> separate parsing for header and body are obviously important
[20:51] <Wes-> however, I could pass around the "stream" like i would a file stream
[20:51] <Wes-> I had to have "is this the header?" logic inside the consumer loop
[20:51] <Wes-> which bites
[20:51] <ashb> Wes-: you know that yield can return a value?
[20:52] <Wes-> ashb: Yes, of course, I was yielding ByteStrings
[20:52] <ashb> sorry i mean: var a = yield; .... gen.next("abc");
[20:52] <ashb> a = "abc" now
[20:53] <ashb> or maybe its .send
[20:53] <Wes-> that's ... wierd
[20:53] <Wes-> It still doesn't solve the problem-pattern I wanted to solve
[20:53] <Wes-> particularly since I wanted to recurse in the consumer
[20:54] <ashb> yeah sending values to yield is a bit of a headfuck at first
[20:54] <ashb> (its send)
[20:54] <ashb> http://pastie.org/692620
[20:55] <deanlandolt> sorry...my friend's mom just called...random
[20:55] <Wes-> I guess maybe my particular example shows that generators may not be the best way to represent file streams
[20:55] <Wes-> deanlandolt: are you sharing your Halls Breezers with her?
[20:55] <ashb> Wes-: depends what you do in the generator
[20:55] <deanlandolt> heh
[20:55] <ashb> i guess you need to cache a few lines inside the generator fn
[20:56] <Wes-> ashb: I was doing while (yield fgets())
[20:56] <deanlandolt> ashb: i imagine you could wrap a generator in a promise and use it just fine
[20:56] <ashb> deanlandolt: perhaps
[20:57] <deanlandolt> but generators aren't going to be ecma standardized any time soon, right?
[20:57] <Wes-> that's right
[20:57] <Wes-> they are also not JITable
[20:57] <deanlandolt> Wes-: that's a pretty nice pattern though
[20:57] <Wes-> (if I understand correctly)
[20:57] <Wes-> wait a minute
[20:58] <ashb> the code *in* the generator should be jittable tho
[20:58] <Wes-> doesn't the filesystem spec say streams are iterators? and jsgi?
[20:58] <ashb> just not hte yield itself
[20:58] <deanlandolt> so is exec just a little stream magic under the hood?
[20:58] <deanlandolt> Wes-: jsgi says nothing about streams -- that's one of the issues i'd like to address -- we should really point to a spec
[20:59] <ashb> Wes-: filesystem spec doesn't define exactly what the streams are
[20:59] <deanlandolt> really? hmm...so who does?!
[20:59] <Wes-> ashb: I meant the first one, that nobody liked
[20:59] <ashb> no one :)
[20:59] <ashb> oh, perhaps
[21:00] <Wes-> deanlandolt: in this case, exec both consumes and yield ByteStrings, which is conceptually the same as streams
[21:00] <deanlandolt> ashb: would it be feasible to make generators respond to forEach?
[21:00] <Wes-> actually, we should probably flip to streams, since they are just { stream: ByteString} anyhow
[21:00] <ashb> deanlandolt: they respone to for (i in gen) {} ;)
[21:01] <ashb> *respond to
[21:01] <deanlandolt> i know...but they'd need to have a forEach explicitly
[21:01] <ashb> deanlandolt: i wouldn't want to grub about in the builtin proto - i'd rather special case them in Zest
[21:01] <deanlandolt> (based on 0.2 and 0.3 at least)
[21:01] <ashb> since they are only a rhino/spidemronkey thing
[21:02] <deanlandolt> ashb: that's fair -- if you could make them respond to forEach and yield objects that respond to toString you've got yourself a standard jsgi response.body
[21:02] <deanlandolt> and you could use them in _any_ jsgi implementation
[21:02] <ashb> true.
[21:03] <deanlandolt> which reminds me -- we should really specify that forEach doesn't return strings but instead objects that respond to toString()
[21:03] <ashb> i thought it was supposedto return a byte string?
[21:03] <deanlandolt> oh...errr
[21:03] <Wes-> heh, and that reminds me of my current favourite hack, which is approprimately ByteString.prototype.toString = ByteString.prototype.decodeToString
[21:03] <deanlandolt> that's right...i suck at this...
[21:04] <deanlandolt> Wes-: i'll be using that
[21:05] <ashb> ah so zest accepts strings or blobs
[21:05] <ashb> if you pass it a string, it encodes it using UTF-8
[21:05] <deanlandolt> yeah, persvr accepts strings too
[21:05] <ashb> if you pass it any other kind of object... it oh. will dir with a random pointer dereference
[21:05] <ashb> go me!
[21:06] <deanlandolt> i think that's fine, but there's good reason to make sure compliant middleware doesn't do that
[21:06] <ashb> sure. but having a bug in your middle ware crashing the server hard is probably less than ideal :)
[21:06] <ashb> *will die with a ...
[21:07] <deanlandolt> i was talking about accepting strings or blobs as response.body...
[21:07] <ashb> ah right
[21:07] <ashb> yeah
[21:07] <deanlandolt> but yeah, it's probably bad to do things that may crash your server hard ;)
[21:09] <ashb> http://github.com/ashb/Zest/blob/master/src/reply.cpp#L259-278
[21:20] <Wes-> deanlandolt: If you use that, you have to have to some idea, FWIW, what the underlying string encoding is. In GPSEE's case, unspecified encoding means "behave the same was the JS_NewStringCopyZ() function", and is a spec extension
[21:21] * Wes- just got some chips.. MMMmMmMmm haven't had these in a while
[21:21] <deanlandolt> Wes-: yeah, that's one of the good reasons compliant middleware shouldn't ever return a string
[21:21] <Wes-> er, "crisps" as far as ash is concerned
[21:21] <ashb> yeah if you return anything but a blob you are at the mercy of the jsgi implementation
[21:22] <Wes-> deanlandolt: Oh, no, String is totally acceptable! As long as you define that String is always UTF-16 in that context
[21:22] <ashb> and it will either die hard or give you something
[21:22] <deanlandolt> i think it's fine for server developers to make assumptions, but still, bad form for app and middleware devs to take advantage of those assumptions and expect interop
[21:22] <Wes-> Or that it is always BLOB
[21:22] <ashb> Wes-: what if you've set a content-type of latin-1?
[21:22] <ashb> etc
[21:22] <deanlandolt> in any event -- it screws up the whole notion of middleware...
[21:22] <Wes-> both have valid interpretations
[21:22] <Wes-> ashb: two ways to look at this;
[21:22] <deanlandolt> so it's probably not good to use anyway, except for simple testing
[21:22] <ashb> if you return a string oyu've got a bug :)
[21:23] <Wes-> 1) We know content-type is latin-1, String is BLOB, so we decode String's lower 8 bits and shove that out as a ByteString at the end of the chain, or
[21:23] <ashb> String is not a blob. ever.
[21:23] <Wes-> 2) We know content-type is latin-1, String is UTF-16, so we decode String to latin-1 ByteSTring and shove *that* out at the end of the chain
[21:23] <Wes-> ashb: that is a matter of definition
[21:24] <Wes-> s/definition/convention/
[21:24] <ashb> Wes-: what you've described is hte job of middle ware right beneath the app
[21:24] <ashb> (in 2)
[21:24] <ashb> but if you generally return a string without knowing you've got such middleware directly beaneath you you've got a Bug
[21:25] <Wes-> ashb: Well, yes, because ATM the spec says "ByteSTring only"
[21:25] <Wes-> If you wanted to use String, you need to decide WTF that means
[21:25] <Wes-> I can see valid arguments for either 1) or 2)
[21:25] <Wes-> I would argue for "ByteSTring only" myself, though
[21:25] <ashb> yeah as would i
[21:25] <Wes-> KISS
[21:26] <deanlandolt> it doesn't say bytestring only
[21:26] <ashb> blob only
[21:26] <Wes-> deanlandolt: what does it say?
[21:26] <ashb> (ByteString or ByteArray)
[21:26] <deanlandolt> it says toByteString :)
[21:26] <ashb> ah
[21:26] <deanlandolt> objects which have a toByteString method
[21:26] <Wes-> deanlandolt: that's equivalently good (and sometimes better actually)
[21:26] <deanlandolt> Strings included
[21:26] <ashb> oh. in which case zest doesn't do the right thing
[21:27] <Wes-> deanlandolt: funnily enough, I suspect ByteString has a conflicting .toByteSTring() method
[21:27] <deanlandolt> ugh
[21:27] <ashb> ByteString.proto.toByteString = function() { return this; }
[21:27] <ashb> is what it should be
[21:27] <deanlandolt> ashb: absolutely...anything else is madness
[21:27] <Wes-> ashb: OH, you're right
[21:27] <Wes-> *phew*
[21:28] <Wes-> I could've sworn I saw something else in there when I was doing code review
[21:28] * Wes- makes a note to go back and look at impl
[21:29] <Dantman> No bs.toByteString(fromCharset, toCharset); ?
[21:29] <Wes-> Good call, Dantman
[21:29] <Wes-> that's what I was thinking of
[21:29] <Wes-> toByteString is variadic
[21:31] <ashb> flusspferd's isn't
[21:31] <deanlandolt> but what's the behavior of bs.toByteString() with no args? is it functionally equivalent to { return this; } ?
[21:31] <ashb> oh i sohuld reply to that es-discuss thread about binary
[21:32] <ashb> so i'm guessing someone addedtoByteString(sourceCharset, targetCharset) after we implemented binary
[21:32] <ashb> i wish mediawiki let you search history
[21:32] <ashb> its history view basically sucks ass
[21:35] <Wes-> ashb: I don't think that's what happened, didn't we implement that before you? (we have it)
[21:35] <ashb> oh perhaps
[21:35] <ashb> either way - i suggest we can't have a (ratified) spec without compliance tests
[21:35] <Wes-> besides which, the mediawiki view is too new, you'd need to look at https://wiki.mozilla.org/ServerJS/Binary/B
[21:36] <Wes-> ashb: Agreed. I gave up running tests because the majority of them depended on much more than what they were testing.
[21:36] <ashb> ah
[21:36] <ashb> well charset transcoding will depend on the encodings module
[21:36] <Wes-> for example, that String would be monkey-patched by calling require("binary")
[21:37] <ashb> haven't we decided against monkey patching it?
[21:37] <Wes-> ashb: No, it depends only on binary. It MAY be implemented with the encodings module. In our case, it is not.
[21:37] <Wes-> ashb: that doesn't mean that narwhal doesn't, nor that it's tests don't demand it
[21:37] <ashb> Wes-: so you only support TFU 8 and 16?
[21:37] <Wes-> ashb: I support whatever iconv does
[21:37] <ashb> ah, you just do it in there. i see
[21:37] <Wes-> yes. That was written long before the encodings module was even thought of
[21:38] <Dantman> Wes-, I did a full history import, all the history from the moz wiki should be there
[21:38] <Wes-> Dantman: orly? didn't know that, thanks
[21:39] <Dantman> Oh.... wait... right... migration
[21:39] <Dantman> Now that I think about it, the migration we have planned is going to affect the wiki
[21:39] <ashb> oh - its running on your company's servers?
[21:40] <Wes-> does it need a short-term alternate home?
[21:40] <ashb> also </3 http://wiki.domain.tld/wiki/
[21:40] <Dantman> along with my own personal stuff ya... It's a small company, I got permission to put what I want there as long as it doesn't eat up bandwidth and jack up costs
[21:41] <Dantman> Not really in need of a temporary home... just good dns migration time
[21:41] <ashb> set the TTL to 30mins in preparation then
[21:41] <Wes-> dantman: trick: set your TTL down to 1800 in your SOA a few days ahead
[21:42] <Dantman> We're probably going to move most of our stuff to a new server
[21:42] <Wes-> "few days" depends on first entry in SOA
[21:42] <Wes-> s/first/refresh/
[21:42] <Wes-> and don't worry, the DNS server can handle the load
[21:42] <Wes-> unless it's a vic-20
[21:43] <Dantman> A) I don't manage the domain. B) The real issue is actually the latency in between when I poke the owner, and when he get's around to switching it
[21:43] <Wes-> need a rootkit?
[21:44] <ashb> wiki.commonjs.org is an alias for voltaire.redwerks.org.
[21:45] <ashb> so either need to get zummbrun to chance the ttl on wiki or on the redwrks one
[21:45] <Dantman> I think I might be able to make due with leaving the dev server on aws online for a bit... It'll be migration anyways, so I'll probably do it piece by piece
[21:46] <ashb> i should really setup a daily backup to happen
[21:46] <Dantman> voltaire.redwerks.org is used to point to that dev server, I probably won't change it to point to the new server
[21:46] <ashb> or rather - to take a copy of the backup
[21:49] <Dantman> I'll probably setup the new server, migrate the source/files, poke for a domain switch, then put the wiki on voltaire into readonly mode and migrate the db...
[21:50] <Dantman> The wiki will just be read only for a little while while the dns switches over to the working wiki
[21:51] <Wes-> dantman: dumb question, if it's only going to take a few days, why not wget --recursive the site, stick a static link up somewhere, cut theCNAME over, migrate in peace, and cut the CNAME back?
[21:51] <Wes-> we have control over the CNAME
[21:52] * Dantman doesn't know when the switch is going to be done yet
[21:54] <JohnnyL> Wes- yay vic-20!! :)
[21:55] <JohnnyL> 1.5 of ram.
[21:55] <JohnnyL> k
[21:55] <Wes-> JohnnyL: No, 5K. 3189 bytes available to BASIC
[21:55] <JohnnyL> oh
[21:55] <JohnnyL> gridrunner!
[21:55] <JohnnyL> a great game.
[21:55] <JohnnyL> or how about Comic Cruncher?
[21:55] <JohnnyL> hehehe
[21:56] <JohnnyL> LDA #WES # Load up Wes- STA $FFD1
[21:57] <Wes-> wow, labels AND comments
[21:57] <Wes-> that's some fancy assembler you got there
[21:57] <Wes-> although, most 6502 assemblers use ; as the comment character
[21:58] <Wes-> not sure why you're right a byte way up there, though. That'd be under the kernel, the VIC doesn't have RAM up there unless you have $5000 worth of memory expansion
[21:58] <Wes-> and an upgraded power supply
[21:59] <deanlandolt> kriszyp: i'm writing that jsgi downgrade middleware...how do i actually resolve a response returned as a promise?
[22:00] <JohnnyL> Wes- opps, too much Python!
[22:00] <JohnnyL> Wes- I know, my last stint with commodore was a kernel based 64 asm editor. :)
[22:01] <deanlandolt> and should the errorHandler also return a jsgi response?
[22:01] <kriszyp> deanlandolt: hmm, I thought we weren't expecting JSGI 0.2 apps to return promises?
[22:01] <Wes-> JohnnyL: the guys in the office next door used to party with Jim Butterfield
[22:01] <deanlandolt> certainly not -- but if a 0.3 app does the promise should be resolved, right?
[22:02] <deanlandolt> plus, i just don't know how to do it...i'm a bit of a promise virgin
[22:02] <kriszyp> right
[22:02] <kriszyp> you mean for the server handler?
[22:02] <kriszyp> sorry, I am a little confused
[22:03] <deanlandolt> oh...i'm backward
[22:03] <deanlandolt> but i still should add that to the 0.2 -> 0.3 -> 0.2 jsgi upgrade middleware
[22:04] <kriszyp> yes, with the upgrade middleware, apps could return a promise, I suppose, but then I think we are just out of luck
[22:05] <kriszyp> although we should be setting request.jsgi.async=false in the upgrade middleware to communicate that we can't handle promises
[22:05] <deanlandolt> are we though? can't we just resolve the promise and turn it into a normal response?
[22:05] <deanlandolt> kriszyp: good point...we are doing that
[22:05] <kriszyp> no, we can't, not before we return from the function
[22:05] <deanlandolt> oh...hmm...i really need to experiment with them -- but the problem is i don't really have any implementations i can experiment on
[22:06] <deanlandolt> i got pintura to build -- i can use that right?
[22:06] <kriszyp> or just use my jack fork
[22:06] <deanlandolt> true
[22:06] <kriszyp> I think it should even have a comet example (hopefully it is up-to-date)
[22:07] <deanlandolt> alright...i'll kick the tires...i really don't understand the mechanics at all -- that's been keeping me from finishing 0.3 draft 2
[22:07] <deanlandolt> cool...will do
[22:07] <kriszyp> in regards to your question about how to duck type, I would say -> if(typeof response.then === "function") ... its a promise...
[22:07] <deanlandolt> yeah...
[22:08] <deanlandolt> but i was under the impression we could also block and resolve that promise at that point
[22:08] <kriszyp> hmm, yeah, we could possibly do that, thats a good point...
[22:08] <deanlandolt> oh...good...i thought my mental model of promises was fundamentally fubar
[22:08] <deanlandolt> glad i'm not totally off
[22:09] <kriszyp> although I think we have stated that require("promise").wait() is not necessarily available on all platforms/concurrency models...
[22:09] <kriszyp> I have implemented it, and node.js has too, it should be implementable in xulrunner based on their API as well...
[22:09] <deanlandolt> hmm...so i guess not
[22:10] <kriszyp> well, it is a reasonable fallback in the upgrade middleware
[22:10] <deanlandolt> well, in any event -- we have jsgi.async for a reason, so compliant middleware must be cognisant
[22:10] <kriszyp> if (typeof response.then ==="function") { response = require("promise").wait(response);}
[22:10] <kriszyp> that's what you would want in your upgrade middleware, I suppose
[22:10] <deanlandolt> cool...i'll start playing
[22:11] <deanlandolt> yeah
[22:11] <kriszyp> but you actually don't want to use wait calls unless you need to
[22:11] <kriszyp> they stack, and so the must be unwound sequentially
[22:11] <kriszyp> it is fine as a backup, but generally JSGI servers will want to be truly async rather than trying to block with wait calls
[22:11] <kriszyp> it is good for the upgrade middleware though
[22:11] <deanlandolt> certainly
[22:12] <deanlandolt> when you say they're unwound sequentially, is it any more of a hit than just doing the thing syncronously?
[22:12] <kriszyp> it is a lot better than sync
[22:13] <deanlandolt> i mean when using .wait
[22:13] <kriszyp> it is like 75% of the way to async ;)
[22:13] <deanlandolt> sweet
[22:15] <kriszyp> I don't know if you will actually be able to find any impl that actually supports the promise module, wait() call, but doesn't support promises in the JSGI server to actually test that though :)
[22:16] <deanlandolt> good point...i was thinking there was a way to just block
[22:17] <kriszyp> I guess its not impossible to do
[22:17] <kriszyp> the promise module is in narwhal now
[22:17] <ashb> so how do promises actually become async?
[22:17] <kriszyp> and so it be feasible in the current narwhal+jack repos
[22:18] <kriszyp> the promises themselves don't make anything async, they just provide the interface for interacting with async stuff
[22:18] <kriszyp> the event queue is the biggest helper for making things async
[22:19] <kriszyp> ashb: are you able to use https://developer.mozilla.org/en/nsIThread
[22:19] <kriszyp> ?
[22:19] <ashb> that looks like XPCom
[22:20] <ashb> kriszyp: but for Zest I envisgage things tying into zest's event loop
[22:20] <kriszyp> do you use XPCom in flusspferd?
[22:20] <ashb> no
[22:22] <kriszyp> in narwhal, this is how the promise module blocks for async: http://github.com/kriszyp/narwhal/blob/master/lib/promise.js#L335
[22:23] <ashb> seems aobut what i imaginied
[22:24] <ashb> whats the true to NextEvent?
[22:25] <kriszyp> tells it to block until an event is executed
[22:25] <ashb> ah
[22:25] <ashb> require("event-queue") is a generic interface to the acutaly event loop, or is an implementation?
[22:26] <deanlandolt> ashb: http://github.com/kriszyp/narwhal/blob/master/engines/rhino/lib/event-queue.js
[22:26] <kriszyp> yeah, in narwhal it does the lookup based on what engine you are in
[22:26] <deanlandolt> rhino-specific...doesn't exist in the default engine
[22:26] <kriszyp> so require("event-queue") should look in wahtever engine is running
[22:26] <ashb> kriszyp: i was thinking it was something like AnyEvent
[22:26] <kriszyp> but we only have the rhino one so far
[22:26] <ashb> which works with glib,libev, etc etc etc.
[22:27] <kriszyp> but the API is modeled after XPCom, so the XUL-running should be ridicously easy
[22:27] <ashb> i'll try and model the one i've got planned for flusspferd/zest around that
[22:27] <ashb> i've never got on with XPCOM. I have intense dislike for it
[22:27] <kriszyp> yeah, let me know if you think we should change the API
[22:28] <ashb> actually, something that i spotted inthe node codebase was interesting
[22:28] <ashb> (unrelated to events)
[22:28] <kriszyp> it was different, but than gozalo wanted to have it work with xul-runner, so I changed it for him
[22:28] <ashb> module.exports = MyClass
[22:28] <ashb> as a way of changing the exports object for a module
[22:28] <kriszyp> instead of exports = MyClass ?
[22:28] <ashb> since doing that you can change it and preserve the singleton need
[22:29] <ashb> exports = MyClass wont actually work in most platforms
[22:29] <kriszyp> the same semantics though, right?
[22:29] <ashb> yeah
[22:29] <deanlandolt> ashb: could you replace module.exports with a callable and have it work across platforms?
[22:29] <kriszyp> well, I've definitely been in favor of something like exports = MyClass;
[22:30] <ashb> deanlandolt: 'a callable'?
[22:30] <deanlandolt> e.g. ~assert.js: module.exports = function(...) {...}; ...
[22:30] <kriszyp> so module.exports === exports (unless you do module.exports = SomethingElse) ?
[22:30] <ashb> yeah
[22:30] <deanlandolt> then just var assert = require('assert');
[22:31] <deanlandolt> assert(foo, 'foo')
[22:31] <ashb> deanlandolt: ah yeah, so you can make the require return a function or a Class is the aim
[22:31] <ashb> tlrobinson: ^^
[22:31] <kriszyp> well, I am still in favor, whatever form it may take (module.exports = ... is fine with me)
[22:32] <ashb> module.exports seems to be the only way to do it and have the circular require thing behave
[22:32] <deanlandolt> i know kriskowal has some /very/ strong opinions on the matter...where he be
[22:32] <ashb> oh yeah - spidemronkey patches. thats what i was working on
[22:38] <tlrobinson> i thought we decided against allowing the user to overwrite "exports" due to problems with circular dependencies?
[22:38] <MisterN> tlrobinson: yeah.
[22:39] <ashb> module.exports allows it while maintaining cirucular dep behaviour doesn't it?
[22:39] <tlrobinson> ashb: does require return module or module.exports?
[22:39] <ashb> module.exports
[22:39] <tlrobinson> then no, i don't think so
[22:40] <ashb> oh, i guess if oyu reset module.exports late on, a circular module could get a different value?
[22:41] <tlrobinson> right, but we also have the same problem if you do var foo = require("bar").foo currently (when foo isn't defined at the time of the call to require)
[22:41] <ashb> hrmmm
[22:41] <ashb> cos being able to have the exports object be a function/class would be really nice
[23:00] <inimino> ashb: what's the problem with exports.foo = myWhatever?
[23:00] <inimino> ashb: is it just the extra property access where require is used?
[23:00] <ashb> inimino: well its like doing this:
[23:01] <ashb> var a = {}; function(a) { a = 2; }; print(a)
[23:01] <ashb> and expecting it to work
[23:01] <inimino> so the problem is that people expect it to work?
[23:02] <ashb> yeah
[23:02] <inimino> after I read the CommonJS modules spec it seemed quite clear on exports, I can't imagine how someone would expect that...
[23:03] <ashb> cos no one but implementors reads specs usually
[23:03] <ashb> and it might be nice ifthat worked
[23:03] <inimino> so it's just a documentation issue?
[23:04] <ashb> dunno - i'd quite like it in some cases still
[23:08] <MisterN> ashb: implementations could make exports throw if somebody wants to change it
[23:08] <ashb> could they?
[23:08] <MisterN> if their engine supports it :)
[23:08] <ashb> not sure how we'd do it given the wya JS modules now behave
[23:08] <MisterN> __defineSetter__ is not portable, i know
[23:09] <ashb> that wouldn't help anyway
[23:09] <inimino> const would
[23:09] <JohnnyL> Wes- too bad the scene is mostly in Europe and even then limited to their own perversions.
[23:09] <ashb> can't defineSetter without exports being a property on some object
[23:09] <MisterN> ashb: hmm it isn't for us?
[23:09] <Dantman> require() throw an error if exports after script exec is different than the original object?
[23:09] <inimino> (which isn't portable or standard either)
[23:10] <inimino> that would work
[23:11] * Dantman prints a warning
[23:11] <inimino> "useless reassignment of ..."
[23:12] <Dantman> Nah, it was something more along the lines of warning that a module redefined exports which was the wrong thing to do, and the module author likely didn't understand how to make a module
[23:12] <inimino> even if it can't be on the relevant line
[23:13] <Dantman> "WARNING: CommonJS module "+identifier+" appears to have replaced the exports object which cannot be replaced. This could be a indication of a programming mistake in that module."
[23:15] <inimino> nice

 

 

Logs by date :