On Wednesday, December 12, 2012 4:36:29 AM UTC-5, Michael Hasenstein wrote:
> ... > > So, can anyone enlighten me - and I MAY INDEED be simply incredibly stupid > not to see the point without help - why node.js could not just let me add > custom parameters for callbacks? Again: additional scope-producing > functions are NOT OPTIMAL IMHO - it produces overhead both in the code and > during runtime. There MUST be a reason, otherwise by now, node.js almost at > version 0.9, would have been changed, wouldn't it? I mean, libraries like > YUI3 give me the option to add my own custom parameters to be passed down > to callback functions, to solve this exact problem. > I blame the folks who designed the DOM APIs, and entrenched this pattern in people's minds. Over the years I've used various libraries in other languages with callbacks, which allow you to register more than just a function with a callback. Typically either an "object", in which case the callback function might be specified as the name of the method on the object, or a "userdata" wad, which is just arbitrary data that is passed to the callback as an additional parameter. Or both! An example is VisualAge Smalltalk UI callbacks, as described here: http://www.scribd.com/doc/53673525/142/Widget-Event-Handling-and-Callbacks Quick example: button addCallback: XmNactivateCallback receiver: self selector: #pressed:clientData:callData: clientData: someData. Which should be read as: "for the 'button' widget, call a callback when the widget is activated (XmNactivateCallback). The callback will send the message #pressed:clientData:callData: with args [button someData activateEventData] to the receiver (self) In JS, you could imagine it like this: button.addCallback("activate", this, "pressed", someData) where the "this" object in this scope has a method "pressed", that looks like this: function pressed(eventObject, clientData, callData) { // eventObject == button // clientData == someData // callData == the event data } Of course, being Smalltalk, there were various shortened versions of the #addCallback: method, when you didn't need to send client data, or needed to pass a block instead of receiver/message, etc. Life was good. Or more declarative and less code-y anyway. Most JS libraries don't have any of this built-in. You can only send a function. So the trick (as you know) is to hook all that other stuff up to the function via bind(), or bind-by-hand by writing wrapping functions. You're starting to see more of this though; Backbone has a "context" parameter for it's "on" function: http://backbonejs.org/#Events-on which lets you do things like this: model.on('change', this.render, this) which handles the case of passing a "this" in (the "receiver" parameter in the Smalltalk example) for the render function, which immediately seems like you'd want to pass in like this instead (but can't, right now): model.on('change', this, "render") You're not going to change the JS universe, which is seemingly stuck forever in the "you only get to associate a function with a callback" mode, but maybe you can build an easier pattern to do the bind, or something. Wonder if macros would help? See: http://sweetjs.org/ -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en