- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Tue, 18 Jan 2005 12:34:48 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Jon Ferraiolo <jon.ferraiolo@adobe.com>, Cameron McCormack <cam-www-svg@aka.mcc.id.au>, www-svg@w3.org
At 02:04 PM 1/18/2005 -0600, Boris Zbarsky wrote: >Peter Sorotokin wrote: >>Surely it is possible. > >All things are possible, with enough effort. The question is whether it's >desirable. I was answering to "This suggestion makes it impossible..." part >>Implementation can temporarily override "public" event type to the type >>before calling the listeners of that type. > >This makes several assumptions about the implementation: > >1) The existence of "public" (and "private") event types. This is simply an explanatory language, e.g. you can save the "private" type in local variable. >2) That the implementation is keeping the event listeners for the two >types in > separate lists (is this desirable? Should registering a listener for > both > types involved make it get the event twice?). You can do it per-listener rather than on per-list basis; but I'd keep two separate lists. >>The only drawback is that is if a listener holds an event beyond the >>duration of the handleEvent call, it might see aliased type; but such >>listener is already asking for trouble. > >Why? I see nothing in the relevant specs saying that the Event object >becomes in some way invalid after the handleEvent() call returns... As far as I remember, DOM spec was pretty clear on the fact that it does not aim to control the lifetime of objects. IMHO, it is perfectly legal implementation strategy to invalidate an event object after it is dispatched. Peter >-Boris
Received on Tuesday, 18 January 2005 20:34:53 UTC