Re: Removal of identifierless getters, setters, etc.

Cameron McCormack:
> > > Would the idea here be to given all of these an identifier but to
> > > declare them as omittable (so that in JS real method wouldn’t exist on
> > > these objects anyway)?

Sam Weinig:
> > Yeah.

Anne van Kesteren:
> Why can't we do this at the binding level of languages without the
> ability?

Because for such bindings, it would be preferable to have consistent
naming for those methods.  Without an identifier in the IDL, there is no
requirement for those other bindings to use a particular identifier.

> Or maybe some generic prose in the Web IDL specification.
> Not sure it is worth making all the definitions more complex as
> these APIs are primarily concerned with ECMAScript anyway. (For
> certain languages you might very well want different APIs.)

The extra complexity is not particularly great.  It is the addition of
two words per definition.

The point about these APIs being suitable only for ECMAScript legacy
stuff, which isn’t obvious and people shouldn’t be using anyway, is a
fair one.  I think that only applies to some of them, though.  Here is
my take on the existing uses of identifierless getters etc. from HTML5:

  * DOMStringMap - name getter, setter, creator & deleter
    http://www.whatwg.org/specs/web-apps/current-work/#domstringmap

    This is used by HTMLElement.dataset.  I think exposing the data-*
    attributes through an API other than getAttribute/setAttribute is
    something that would be useful for languages other than ECMAScript,
    even if it isn’t through a handy property access mechanism.

    I could imagine in Python an object that exposes the data-*
    attribute like in ECMAScript, per
    http://docs.python.org/reference/datamodel.html#customizing-attribute-access.

    For languages that do not support properties like this, having
    regular, named methods seems like a fine default.

    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?

  * HTMLDocument - name getter
    http://www.whatwg.org/specs/web-apps/current-work/#dom-document-nameditem
    
    This is used to access named elements within the document.  This
    seems to me like it is just included for legacy.  We have
    document.getElementsByName() and document.getElementById() to
    provide access to elements by their name="" or id="" attributes.

    I think it is OK for this getter to be ECMAScript-specific.

  * Window - name getter, index getter
    http://www.whatwg.org/specs/web-apps/current-work/#dom-window-nameditem
    http://www.whatwg.org/specs/web-apps/current-work/#dom-window-item
    
    The index getter is used to access all of the child browsing
    contexts of the window.  There doesn’t seem to be another easy way
    to do this, so assuming this is a valid use case we want to support,
    I think the index getter should have an identifier.  Especially
    since the length property will exist on the window.

    The name getter is used to access elements in the document by name
    or ID, but subtly differently from the name getter on HTMLDocument.
    Again, I think this one is OK to be ECMAScript-specific.

  * 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.

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

    These are used to get and set pixel values on a <canvas>.  There is
    no other way to access the pixel data.  I think these should have
    identifiers.


So in the list above there are a couple where I agree that they wouldn’t
be useful to have in non-ECMAScript bindings.  Sam (and others who were
in favour of the resolution): do you think the above supports the
retention of identifierless getters etc.?

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 13 October 2010 22:27:50 UTC