RE: Level 3 Events

Joseph Kesselman [mailto:keshlam@us.ibm.com] wrote:
> Name overlap on the methods: Names are scoped to an 
> object.Consider just how many Java objects use add(), for 
> example. Since you have to say what you're adding _to_, I 
> don't see reuse of the add method's name as a problem
> -- if anything, I think I prefer consistancy.

However, one object is rarely required to support multiple methods (on distinct interfaces) with the same name and different signatures.  It isn't an issue with Java which can easily support
identically named methods with different signatures, however if you were accessing an Node object from JavaScript from COM where all the supported abstract interfaces are lumped into one big default
IDispatch interface where using the same name on the same interface with different signatures is not supported.

You had a similar situation with the namespace variants of DOM 1 methods.  For example, you could have defined a second createElement signature, however it was decided (for probably the same reason),
to use distinct names for createElement and createElementNS.

> >You could potentially add the same listener to the same 
> event target on 
> >multiple groups.  Should the Event or EventListener interface be 
> >extended
> so >that you could detect which group is active?
> 
> That depends on whether a listener gets called once if it's 
> in any group which is still active, or once per group. I 
> don't remember what we decided on that front. If it's only 
> once, you don't need to know which group it was. If it's 
> multiple... I think that's like adding the same listener 
> multiple times to L2 events; probably not a good idea to begin with.

Having a listener fired only once when it is in multiple active groups on the same target seems reasonable, however it will effectively restrict the dispatch algorithm to have targets as the outer
loop and groups as the inner loop.  If a multiply registered listener is only fired once and calls stopPropagation, then I guess it should stop propagation for all groups for which it is registered on
that target.

The use of distinct interfaces for the Level 3 capabilities seems to contradict the general trend just to append new methods to the previous interface definitions,  For example, createElementNS was
just appended to Document in Level 2 instead of a DocumentNS interface being defined.  All the group related methods would seem to be prime candidates just to stick at the end of the existing
DocumentEvent and EventTarget interfaces.

Has there been any thought about introducing a distinct Java namespace for Level 3 versions of the DOM interfaces?

Received on Friday, 3 August 2001 15:46:31 UTC