Re: Subclassing DOM nodes

>BTW, using events as an extensibility mechanism also
>implies that it needs to be FAST.  If the event course of
>extensibility is taken, there needs to be an investigation
>on how performance of the event system can be improved.
>I would not like to think that the DOM Events API
>intrinsically imposes a poor performance event system
>on all DOM Event implementations.

Designing for generality usually does impose some costs.The DOM Event
system may not be ideal for all applications which need event-like
behavior. It shouldn't have to perform "poorly" (though actual performance
is, as always, up to the individual implementation), but it may not perform
as well as an event system which was precisely tailored and tuned to a
specific application.

In this case: If all you want is to call an additional behavior on a single
node, the overhead of having to construct an object to carry its
parameters, having to look up the function by name, and having to be
prepared for the possibility that the event may be distributed to other
listeners all contribute overhead that wouldn't exist in the simple
subclassing case. It's roughly the same kind of overhead as calling a Java
method via reflection... _plus_ having to search for capturing handlers,
even if bubbling is turned off.

______________________________________
Joe Kesselman  / IBM Research

Received on Thursday, 12 October 2000 09:58:04 UTC