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
