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<>  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.connect( targetObj, "event-type", handlerObj );

  bind( type, data, fn )
  one( type, data, fn )
  trigger( event, data )
  triggerHandler( event, data )
  unbind( type, fn )

  $('foo').observe('click', respondToClick);

  static Boolean addListener  ( el , sType , fn , obj , overrideContext )

  connect('myID', 'onclick', myClicked);
  signal('myID', 'onclick', fakeEvent);

  addHandler(AbstractEventHandler handler)
  fireEvent(Object target, String type, Class clazz?, Array args?)
  ... (a whole lot more)

Ext JS

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.

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

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