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

2010-02-02:

[15:30] <voodootikigod> kevin dangoor, you in here
[15:35] <ashb> voodootikigod: only very rarely
[15:35] <voodootikigod> i must track him down!
[15:35] <ashb> email or twitter probably best
[15:37] <voodootikigod> cool thanks
[15:56] <ashb> voodootikigod: so when is the schedule for JSConf.US out?
[15:57] <voodootikigod> umm
[15:57] <voodootikigod> define schedule
[15:57] <ashb> list of speakers and what not
[15:58] <voodootikigod> we sent out first half of speaker invites last night
[15:58] <voodootikigod> we will post them as they accept
[15:58] <ashb> k so soon
[15:58] <voodootikigod> and second half goes out as soon as we can lock it down
[15:58] <voodootikigod> there were 100+ submissions
[15:58] <ashb> blimey
[15:58] <voodootikigod> yea
[15:59] <voodootikigod> but there will be all inclusive parties saturday and sunday
[15:59] <voodootikigod> and either a meetup or a full party friday night
[15:59] <voodootikigod> depends on final details
[15:59] <voodootikigod> we had to pilage friday for the sat/sun but I think a sponsor is going to step up and take friday
[15:59] <voodootikigod> which will work great
[16:05] <ashb> voodootikigod: probably worth sending out a 'sorry your talk was not accepted' or 'heres the schedule of speakers' to everyone who didn't get accepted
[16:06] <voodootikigod> we will once final set is made
[16:06] <voodootikigod> and all people who put in will get the pirate ticket price
[16:10] <ashb> k
[17:00] <nrstott> I've got a theory question for the JS gurus here. When is it appropriate to use callbacks and when is it appropriate to use promises? What use-case is better-suited to callbacks and what use-case is better-suited to promises?
[17:00] <deanlandolt> nrstott: simple answer, to the best as i've been able to gather, is it's best to use callbacks when an event can be raised multiple times
[17:01] <nrstott> ok, so when youd otherwise use continuation-passing-style, then a promise is more appropriate?
[17:01] <deanlandolt> but if it's a single event a promise gives you a nicer (IMHO) model
[17:02] <deanlandolt> nrstott: to me it is -- but as you may be able to tell there's quite a few different opinions on the matter :D
[17:02] <ashb> deanlandolt: a cb is almost always less typing isn't it?
[17:02] <nrstott> i think a lot of people confuse 'callbacks' with 'continuation-passing-style' too which makes figuring out what people are saying more difficult
[17:02] <ashb> so why does promise give a better model?
[17:03] <nrstott> so deanlandolt, you are saying that $.ajax from jQuery would be an inappropriate place to use promises since the success, error, and complete callbacks are raised only one-time each
[17:04] <nrstott> just as an example
[17:04] <deanlandolt> ashb: a promise is almost always /less/ typing when you're using a library helper like with(
[17:04] <ashb> deanlandolt: really?
[17:04] <ashb> x.op(args, cb);
[17:04] <ashb> is the form i had in mind
[17:05] <deanlandolt> okay, so about the same amount of typing :D
[17:05] <deanlandolt> nrstott: i think $.ajax would be a great place to use promises
[17:05] <deanlandolt> if you consider promises to be the asyncronous equivilant to a function
[17:06] <deanlandolt> ashb: when(somePromise, fn)
[17:07] <deanlandolt> what's better -- it doesn't actually /have/ to be a promise...gives you more flexibility
[17:07] <nrstott> deanlandolt, so how would $.ajax look with promises
[17:08] <deanlandolt> nrstott: when($.ajax({...}), successFn, errorFn);
[17:09] <nrstott> what about the completeFn?
[17:09] <nrstott> just add that onto the end?
[17:09] <deanlandolt> the more verbose but dependency-free form would be $.ajax({...}).then(successFn, errorFn);
[17:09] <deanlandolt> yes, they're chainable
[17:09] <nrstott> that looks worse to me because you're obfuscating which function does what. i like how in the {} you have { success: function() ... } error : }
[17:09] <deanlandolt> yeah, naming your handlers does have its merits
[17:13] <nrstott> so what merit does the promise have that makes up for that?
[17:14] <deanlandolt> one example -- if you don't know if the fn you're calling will always return a promise
[17:15] <ondras> Wes-: ssh: connect to host 66.102.69.55 port 22: No route to host
[17:15] <nrstott> deanlandolt, what's an example situation where you wouldn't know that?
[17:15] <deanlandolt> jsgi middleware
[17:15] <nrstott> ok, wont JSGI middleware always return a function?
[17:16] <deanlandolt> sometimes you just want to return {body: []}
[17:16] <deanlandolt> it always returns an object
[17:16] <deanlandolt> but not always...it can return a promise
[17:16] <deanlandolt> so middleware can just use when(app(request), function(response) {...}) ...try that w/ callbacks
[17:17] <nrstott> ok i dont get what that does
[17:17] <Wes-> ondras: argh, new dhcp lease, brb
[17:17] <nrstott> can you break it down for me? :)
[17:17] <deanlandolt> sure...app(request) is effectively app(env) from jsgi 0.2 -- i like calling it request but the spec doesn't care what you call it...
[17:18] <nrstott> when i think jsgi middleware i think of wrapping app(request) with a new Middleware(app) { return function(request) { ...dostuff... return app(request); } }
[17:18] <deanlandolt> so app(request) could return your standard {status..headers...body} obj
[17:18] <deanlandolt> but inside the middleware it has to call out to the next app in the chain
[17:19] <deanlandolt> perhaps i should use kris zyp's convention and call app nextApp instead
[17:19] <ondras> Wes-: thanks
[17:19] <deanlandolt> but in any event, nextApp(request) just passes the call down into the middleware chain
[17:19] <Wes-> ondras: better?
[17:19] <deanlandolt> the response should be a valid jsgi response, which means the status/headers/body object /or/ a promise
[17:20] <deanlandolt> that promise, when resolved, will be a valid jsgi response
[17:20] <deanlandolt> rather, it'll have a "then" function that takes the valid jsgi response as its argument
[17:21] <deanlandolt> the require("promise").when construct juts calls "then" under the hood if it's a proimse, or calls your fn immediately with the response if it's not
[17:22] <deanlandolt> thus, when(nextApp(request), function(response) { ... });
[17:22] <ondras> Wes-: nice, thanks
[17:22] <nrstott> woudln't it be more elegant if nextApp(request) always returned a promise so we could just write nextApp(request).then(function() ... )
[17:23] <deanlandolt> nrstott: define elegant...if we required that then simple jsgi apps would always have to generate a promise
[17:23] <nrstott> is generating a promise that big of a deal?
[17:23] <nrstott> elegant: consistant, clean, predictable
[17:24] <deanlandolt> it's not a big deal -- but it's a few extra lines of code /every/ time...
[17:25] <deanlandolt> a valid jsgi app could no longer be return {status: 200, headers:{}, body:["hello"]}
[17:25] <deanlandolt> to me ^^ is elegant -- anything that /requires/ a dependency is less elegant
[17:25] <nrstott> it could be return makePromiseOutOf({ status:200, headrs: {}, body: ["hello"] })
[17:26] <ashb> aka when()
[17:26] <deanlandolt> yep, still not quite as nice but worse, it fundamentally /requires/ a dependency
[17:27] <deanlandolt> plus it breaks everything jsgi as it exists today
[17:27] <deanlandolt> instead of just incrementally building on it
[17:28] <nrstott> ive got quite a bit invested in JSGI with Bogart and a site in production, and I would be ok with that
[17:28] <kriszyp> btw, in my narwhal promise module, whenPromise is like when, except it always returns a promise
[17:28] <nrstott> i would be fine altering my middleware to always return a promise
[17:28] <ashb> nrstott: i'm not happy with breaking back-compat without a *very* good reason
[17:28] <ashb> just on general principles
[17:29] <nrstott> ashb, the good reason is becaus JSGI is young and if we can do something that makes more sense, then it's still young enough
[17:29] <nrstott> not breaking back-compat is what makes things liike python 3.0 eventualy have to happen, then the mess is worse than if it'd be fixed years ago ;0
[17:29] <deanlandolt> nrstott: but i don't see how it makes more sense
[17:30] <deanlandolt> at least, i'm not convinced ditching simple sync responses helps
[17:30] <nrstott> i guess im not comfortable with having to test the return value of everything to see if it's a promise or if its an actual response
[17:30] <deanlandolt> especially when it's so easy to accomodate both
[17:30] <nrstott> i know you can have a helper for that, but that fundamnetally smells to me
[17:30] <deanlandolt> smells worse than makePromiseOutOf?
[17:30] <nrstott> much worse
[17:31] <ashb> other way round to me, needing a helper to have the common/simple case is wrong
[17:31] <deanlandolt> ashb++
[17:32] <deanlandolt> the complex case shouldn't /require/ helpers either...but that's where they should come in handy
[17:32] <nrstott> it just seems very inconsistant API wise to not know whether you're getting a promise back or an object.
[17:33] <deanlandolt> nrstott: i hear you
[17:33] <ashb> promise is just an object with different porperties, so its still an object isn't it?
[17:33] <nrstott> ashb, you got me there :)
[17:33] <ashb> or is a promise a function?
[17:33] <ashb> (i dont actually know)
[17:33] <nrstott> i think tis an object
[17:33] <deanlandolt> a promise is an object
[17:33] <deanlandolt> with a then function
[17:33] <deanlandolt> and some other stuff, i imagine, but definitely a then function
[17:33] <ashb> (functions are objects, of course, but thats not what any of us mean)
[17:37] <nrstott> the promise API looks elegant to me... doSomethingThatReturnsAPromise().then(.. do other stuff)
[17:37] <nrstott> that looks awesome
[17:37] <nrstott> i like the 'fluent' feel
[17:37] <deanlandolt> nrstott: i agree
[17:38] <nrstott> i guess there's nothing stopping me from just using promises and requiring they be returned in my framework code outside of JSGI ;0
[17:38] <deanlandolt> and generally you can use that all over the place...it's just in /fully/ complaint middleware you would have to use something like when...but i don't see that as a huge issue -- you can always write async-ONLY middleware if you'd like
[17:38] <nrstott> so what JSGI does there isn't of grave importance i suppose
[17:38] <nrstott> its just something to leanr to deal with when writing JSGI middleware
[17:39] <deanlandolt> yeah, only when you want to write completely reusable middleware, which isn't really all that necessary most of the time
[17:39] <deanlandolt> in fact, having response.body return a lazy array of objects is /really/ useful in a lot of cases
[17:40] <nrstott> so how do you handle 'errors' with the promise .then(...) api?
[17:40] <deanlandolt> the second arg
[17:41] <nrstott> so .then(successFn, errorFn)
[17:41] <deanlandolt> exactly
[17:41] <deanlandolt> or when(promise, successFn, errorFn)
[17:41] <nrstott> alright, im on the same page now
[17:42] <deanlandolt> took me a bit of beating it around before it all sunk in (i'm pretty slow though, and async kinda makes my head hurt -- but i'm getting better :)
[17:43] <nrstott> is commonjs going to define async file IO ?
[17:44] <deanlandolt> i hope :-/
[17:44] <ashb> in theory, yes.
[17:44] <[k2]> imho, the current implementation of promises are not really promises, but more like event emitters.
[17:45] <ashb> [k2]: probably. tho i'm not sure of a canonical defn of promises
[17:45] <[k2]> then again, my first exposure to promises was with something less like event emitters: http://github.com/ShiftSpace/promises
[17:45] <nrstott> my first exposure to promises was very different as well...
[17:46] <nrstott> they were used in NHibernate to allow composure of queries
[17:46] <nrstott> or not really NH, Rhino Tools which was built around it
[17:49] * Wes- nods @ 'fluent feel'
[17:49] <Wes-> A good-feeling API is important for end-using programmers
[19:26] <rektide> ProxyAPI... is anyone actually implementing it ?
[19:27] <rektide> http://wiki.ecmascript.org/doku.php?id=strawman:proxies
[19:27] <rektide> cause... wow. damn.
[19:28] <tlrobinson> yeah its going to be awesome
[19:30] <rektide> "going to be" is kind of what i'm wondering about
[19:30] <rektide> where in the greater lifecycle of becoming a usable API is it
[20:01] <ashb> rektide: last time i lokoed at the strawman it looked very hard to implement from outside the lib
[20:23] <rektide> ashb: i dont know what "from outside the lib" is referencing
[20:23] <ashb> rektide: as in without hacking on the internals of v8/spidermonkey etc
[20:23] <ashb> i.e. oyu can't do it using just their public APIs
[20:23] <rektide> oh, almost certainl yimpossible, yes
[20:24] <rektide> i dont really know what context the proposal stands in
[20:25] <ashb> generally accepted i think
[20:25] <ashb> it got discussed at the TC39 meeting last week
[20:25] <rektide> who would ratify it ?
[20:25] <rektide> yes i noted that. seems to be overall rather favorable.
[20:27] <rektide> is the goal to be ratified in ecmascript 5 ?
[20:29] <ashb> 5 is already ratified
[20:29] <ashb> so no
[20:31] <rektide> i'd thought so. was looking through the TC39 charter. TC39 would approve this, as what, part of 5.1 or some such? it does eventually intend to be a core part of ecmascript...
[22:30] <deanlandolt> kriszyp: i modified your simple-worker to do request.body as a forEach and take response.body as a possible async stream: http://github.com/deanlandolt/jack/blob/promises/lib/jack/handler/simple-worker.js
[22:30] <kriszyp> excellent
[22:30] <deanlandolt> does that look right to you? i'm still hacking around at it -- rewriting the multipart middleware now
[22:31] <kriszyp> yeah, looks great
[22:31] <kriszyp> too bad you can't do the request input async
[22:32] <deanlandolt> yeah
[22:32] <kriszyp> good job, though
[22:32] <deanlandolt> disappointing
[22:32] <deanlandolt> thanks
[22:32] <kriszyp> hopefully the multipart isn't too painful...
[22:33] <deanlandolt> oh, it'll be painful...but awesome
[22:33] <deanlandolt> it'll return a lazy array of request-like objects containing the headers obj and a body that's a forEachable...
[22:33] <deanlandolt> which can contain nested multipart
[22:34] <deanlandolt> so yeah, it'll be "non-standard" but more useful that way
[22:37] <kriszyp> nice

 

 

Logs by date :