W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

Re: Removal of identifierless getters, setters, etc.

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 14 Oct 2010 06:30:36 +0000 (UTC)
To: Cameron McCormack <cam@mcc.id.au>
cc: Anne van Kesteren <annevk@opera.com>, Sam Weinig <weinig@apple.com>, public-script-coord@w3.org
Message-ID: <Pine.LNX.4.64.1010140622570.5810@ps20323.dreamhostps.com>
On Thu, 14 Oct 2010, Cameron McCormack wrote:
>   * DOMStringMap - name getter, setter, creator & deleter
>     http://www.whatwg.org/specs/web-apps/current-work/#domstringmap
>     HTML5 currently says of DOMStringMap:
>       Note: The DOMStringMap interface definition here is only intended
>       for JavaScript environments. Other language bindings will need to
>       define how DOMStringMap is to be implemented for those languages.
>     I think it is fine to defer the exact binding of particular
>     interfaces to those people writing the bindings for that language,
>     but it seems like we can get reasonable defaults here, so why not
>     have them?

How can we? For a language like C++, the only sane thing I can think of 
here would be to expose a method to get, a method to set, and a method to 
delete, but then that's no better than getAttribute, setAttribute, and 
removeAttribute, so C++ should just not have the feature.

>   * TimedTrackCueList - index getter
>     http://www.whatwg.org/specs/web-apps/current-work/#timedtrackcue
>     This provides index-based access to the TimedTrackCue objects in a
>     list.  There is no other way to access the TimedTrackCues without
>     knowing their name.  I think this one should have an identifier.
>     Already raised as
>     http://www.w3.org/Bugs/Public/show_bug.cgi?id=11016.

This should just be an array in languages where that's possible. The only 
reason it's not an array/sequence in JS is that it provides a useful place 
to hook the "getCueById()" method without losing the array-like behaviour 
(I'm assuming we'll fix the problem of collections, nodelists, etc, not 
being fully array-like, and then that'll fix the similar problem here).

In a language like C++, you'd want the getCueById() method on whatever 
object returns the TimedTrackCueList object, you wouldn't have an actual 
TimedTrackCueList object. In a language like Perl, you'd just bless an 
arrayref and add the method on the corresponding class.

>   * CanvasPixelArray - index getter, index setter
>     http://www.whatwg.org/specs/web-apps/current-work/#dom-canvaspixelarray-get

That should just be an array, that part of the spec predates WebIDL having 
native array syntax.

We know what happens when people take the IDL design for JS and apply it 
to other languages: we get what happened when people wrote IDL for Java 
and applied it to JS, namely, a poorly-designed API. IMHO, WebIDL 
shouldn't be language agnostic. There should be a specific IDL provided 
for each language supported. In some cases they might be very similar, but 
simply taking the JS one and using it elsewhere is not good practice.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 14 October 2010 06:31:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC