Re: addEventListener naming

Hi, Jonas-

Jonas Sicking wrote (on 9/12/09 5:42 PM):
> On Sat, Sep 12, 2009 at 2:37 PM, Doug Schepers<schepers@w3.org>  wrote:
>>>  4. More methods for the developer community to learn. While learning
>>>  both isn't needed to write code, it is needed to read other peoples
>>>  code. Ability to read and understand other peoples code is a major
>>>  strength of the web platform.
>>
>>  Agreed, but we already have a proliferation of new shorthand method names
>>  through script libs... might it not be better to have some standard shorter
>>  names that are better documented?
>
> True. If lots of libraries are supplying short-hand names, then it's
> an indication that there's a real problem that needs to be solved. Do
> a lot of libraries add shorthands for addEventListener?

Here are some similar constructs:

dojo
 
<http://www.dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo/functions-used-everywhere/dojo-connect>
  dojo.connect( targetObj, "event-type", handlerObj );

jQuery
  <http://docs.jquery.com/Events>
  bind( type, data, fn )
  one( type, data, fn )
  trigger( event, data )
  triggerHandler( event, data )
  unbind( type, fn )

Prototype
  <http://www.prototypejs.org/api/event>
  $('foo').observe('click', respondToClick);

YUI
 
<http://developer.yahoo.com/yui/docs/YAHOO.util.Event.html#method_addListener>
  static Boolean addListener  ( el , sType , fn , obj , overrideContext )

MochiKit
  <http://www.mochikit.com/doc/html/MochiKit/Signal.html>
  connect('myID', 'onclick', myClicked);
  signal('myID', 'onclick', fakeEvent);

qooxdoo
  <http://demo.qooxdoo.org/current/apiviewer/#qx.event.Registration>
  addHandler(AbstractEventHandler handler)
  fireEvent(Object target, String type, Class clazz?, Array args?)
  ... (a whole lot more)

Ext JS
  <http://www.extjs.com/products/extcore/manual/>
  addListener/on
  removeListener/un

Most of these also add little bits of functionality to 
'add/removeEventLister()', which is predictable... they each want to 
make it fit their own architecture model, so why stop at a simple renaming?

So, to answer your question: yes and no.  Perhaps if we are going to add 
a new event listener method, we should examine the most common use cases 
and add functionality accordingly, rather than just rename it.  I don't 
think that quite matches Alex's use case of a universal JS signal 
dispatcher, but it's not clear that that would get wide support.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Saturday, 12 September 2009 22:51:45 UTC