Well, DOM Event API defines the EventListener interface. you could do this:
document.body.addEventListener('click',
{foo:'foo',handleEvent:function(ev){console.log(this.foo)}})
and this will print foo to your console, but thats, right. it's possible
just to pass a function and most of devs do this and use closure scope
instead or even bind.
Am Mittwoch, 12. Dezember 2012 16:35:50 UTC+1 schrieb Patrick Mueller:
>
> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
