Here's a thought:  bindAsEventListener() is basically bind() where a
certain number of leading args are expected at call-time and the rest
are provided at bind-time.  (Unless you use it to create DOM0-style
handlers on IE; Don't Do That, this is 2009.)  So perhaps the symbol
bindAsEventListener can be deprecated -- people *really* get the wrong
idea, thinking they have to use it for all event listeners -- and the
functionality replaced with a generalized routine that binds and
partially applies with a leading gap.  Just for illustration purposes,
here's a *completely* untested and un-optimized version based on's bindAsEventListener:

  bindWithGap: function(context, gap) {
    var __method = this, args = $A(arguments).slice(2);
    return function() {
      var newargs = $A(arguments);
      newargs.length = gap;
      return __method.apply(context, newargs);

(Again, that hasn't been improved with any of the goodness discussed
so far in this thread.)  So this code:

$('foo').observe('click', this.spiffyHandler.bindAsEventListener(this,
'spiffy', 'args'));


$('foo').observe('click', this.spiffyHandler.bindWithGap(this, 1,
'spiffy', 'args'));

The deprecation API doc entry for bindAsEventListener() would explain
this stuff and reference the use of bind() or, in highly specific
situations, bindWithGap (and point DOM0 folks at Event#observe /
Element#observe, or show them how to create their own like-for-like
bindDOM() function).

-- T.J. :-)

On Mar 15, 12:00 am, Tobie Langel <> wrote:
> Right. And that warrants clear(er) documentation and not deprecation,
> as there is no other way to handle partial application in event
> handlers.
> On Mar 14, 7:10 pm, kangax <> wrote:
> > On Mar 14, 11:43 am, Tobie Langel <> wrote:
> > > I'd like to see how we can combine all of this elegantly with
> > > bindAsEventListener and curry.
> > I personally don't understand the need for `bindAsEventListener` at
> > all. It's the most misunderstood method in Prototype. Its scope of use
> > is so narrow that it makes sense to deprecate it.
> > To explain:
> > `bindAsEventListener` guarantees that an event object is being passed
> > as a first argument to an event handler. The problem is that every
> > single use of `bindAsEventListener` that I've seen is used with
> > `observe`. When `observe` uses `attachEvent` (in MSHTML DOM) it
> > already does pass event object as a first argument to event handler
> > (which makes `event || window.event` in `bindAsEventListener`
> > redundant). `bind` suffices most of the time, except when a partial
> > application is used (or, of course, if you're not using `observe` in
> > the first place, but an intrinsic event attribute).
> > Another problem is that `bindAsEventListener` is almost *never* used
> > with partial application (look at Scriptaculous, for example, or
> > practically any other snippet on the web).
> > What this all means is that these 2 expressions are functionally
> > identical (considering that they are called from within the same
> > execution context):
> > myElement.observe('click', onClick.bind(this));
> > myElement.observe('click', onClick.bindAsEventListener(this));
> > And there's absolutely no need to use the latter one.
> > myElement.observe('click', onClick.bindAsEventListener(this, 'foo',
> > 'bar'));
> > - on the other hand, ensures that an event handler, when called, will
> > have an `event` object as a first argument (i.e. "foo" and "bar" will
> > be second and third arguments, rather than first and second). This is
> > exactly what's misunderstood about this method.
> > [...]
> > --
> > kangax
You received this message because you are subscribed to the Google Groups 
"Prototype &" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to