[Webkit-unassigned] [Bug 77835] [GObject bindings] EventListeners as first-class GObjects: WebKitDOMEventListener

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=77835





--- Comment #35 from Zan Dobersek <zandobersek at gmail.com>  2012-03-13 13:13:41 PST ---
(In reply to comment #34)
> (In reply to comment #33)
> > > b/Source/WebCore/bindings/gobject/WebKitDOMCustom.h:58
> > > +WEBKIT_API void webkit_dom_event_listener_set_handler(WebKitDOMEventListener* self, GClosure* handler);
> > 
> > The DOM spec does not allow these sorts of manipulations on an event listener, and I am of a very strong opinion that we shouldn't neither.
> 
> i'm very much the opposite -- the DOM spec doesn't specify anything really, and EventListener is an technically only an interface ... i mean not even _create() would be permissible then, except by necessity.  by enabling the *real* handler to be swapped dynamically, at no cost or code complexity, add a LOT of power and flexibility -- isn't this useful?  imagine 200 Targets that all shared a Listener, but with varying event types ... not simple/fast to update, and expensive to update from a binding (marshall back/forth hundreds of times).  by exposing a this we can change the backing handler in a single operation from any language ...
> 
> you can think of it as a detail being exposed to the DOM implementation, NOT the DOM spec (spec doesn't undestand GCallback/etc, eg. _create(), setHandler()), so it doesn't violate anything IMO.
> 

DOM spec clearly specifies the EventListener interface, and that should be implemented. There are extensions to be made, such as the _create() method, but, as said, this is out of necessity. Other additions simply should not be made. DOM implementation should closely follow the spec and not deviate from it.

Given the test case of 200 targets, find the solution within the constraints of the DOM spec rather than exploiting a DOM implementation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.