Thomas DeWeese:
> To be clear of the issue. Someone might pass us an instance
> of this interface and we wouldn't be able to find these methods
> because if we cast it to the DOM Event interface it might be a
> DOM2 Event interface lacking these methods, so our calls would
> fail (not to mention that people compiling would have to have
> the DOM3 Event interface early in the path so the methods would
> appear). Is this the main concern?
That's right.
> As long as there is only one or two of these classes my
> leaning would to create 'wrapper' classes that implements our
> version of the interface and use Java reflection to call the
> methods on the wrapped instance. Then we can check if the
> instance passed in implements our interface if so just cast and
> use, otherwise wrap it and use it.
Ok. Though it's all probably moot since DOM 3 custom events are broken
anyway. :-)
> I would strongly prefer to avoid modifying W3C classes/interfaces
> especially in the W3C packages, unless it is clearly an error (and
> even then preferably with working group approval).
Sure, it will be cleaner with the reflection.
How about after I make these changes, I try merging in the trunk to
svg12, make sure it all works properly, then merge the differences back
to the trunk?
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
