Re: addEventListener naming

Alex,

> >>>  Alex Russell wrote (on 4/24/09 5:31 PM):
> >>>>
> >>>>  The DOM function "addEventListener" is
> probably too long. It should,
> >>>>  instead, be named something much shorter
> owing to the amount of
> >>>>  exercise it receives. Further, it should
> default the last parameter to
> >>>>  be "false" (non-capture-phase). 

This is a great suggestion. WebKit, for example, already defaults the capture parameter.

> >>>>  And given how common this operation it,
> it should probably have an
> >>>> alias:
> >>>>
> >>>>      node.listenOnce("click",
> function(e) { /* ... */ });

I doubt that registering an event listener for a single execution is a common pattern. You might need it in some cases, but definitely not often.
Adding just one line of code, that would unregister event listener, is not a big deal in the rare situations, right?

node.addEventListener("click", function(event) {
    /* */
    this.removeEventListener(event.type, arguments.callee);
})


> Nope, I'd like to propose that a listen() method be added
> to ALL
> objects in JS. The goal here is to unify JS and DOM
> behavior.
> Hierarchy, bubbling, etc. probably don't apply in the
> non-DOM case,
> but one could image an interface that objects could
> implement (say,
> and eventParent property) to delegate dispatch "up" the
> chain.
> 
> Regardless, it's crazy that we have one way of thinking
> about "events"
> in DOM (a terrible, Java/C++-centric API) and one way of
> thinking
> about events in JS (ad-hoc AOP-style systems and
> monkey-patching).

To my understanding, you are trying to introduce a high-level pattern to a low-level technology, thus merging separated concerns.
What I mean is - the concept of "notifications" is often used in application logic, while such of "events" is used in the GUI.

> Rate-limiting has always been a problem. Also, I didn't
> mention it
> before, but generating events today is just a travesty.
> It's terrible,
> particularly for kbd events. Making it work more like
> function
> dispatch and less like cons-ing up some sort of funky
> implementaiton
> object with opaque params would be a step in the right
> direction.

The browser events (particularly "kbd events") are not supposed to be dispatched by the script author. Moreover, I think this should be even disallowed. 

Seregy/

Received on Thursday, 27 August 2009 10:19:49 UTC