Re: Removal of identifierless getters, setters, etc.

Maciej argues the case more eloquently than I was going to.  I think his
point number 1 (non-JS bindings matching more or less the JS bindings,
so that developers can reuse their knoweldge) is a good one, and one
that I have observed as people use the Java bindings for SVG content in
Batik, too.

On the specific interfaces:

Cameron McCormack:
> >   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?

Ian Hickson:
> 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.

It does provide some benefit; namely, it ensures that you only set data
attributes with valid names (the case folding with dashes thing).

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

That the list of TimedTrackCues can change (e.g. with a call to addTrack)
might mean that arrays aren’t really appropriate.

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

Really?  I would think a more faithful translation of the IDL interface
into a C++ class would be fine:

  class TimedTrackCueList {
  public:
      unsigned long length();
      TimedTrackCue* operator[](size_t index);
      TimedTrackCue* getCueById(const domstring& id);
  };

Or thereabouts.

> In a language like Perl, you'd just bless an arrayref and add the
> method on the corresponding class.

Again, not sure that arrays are appropriate here.  (Plus blessing arrays
isn’t a common idiom, is it?)

Anyway, the point isn’t that the bindings are going to be perfect for
all possible present and future languages, but I think with thoughtful
design of the interfaces (as well as the features of Web IDL) we can get
good defaults.  If we get bad interfaces for non-JS languages out of
these defaults, and adding some more suitable abstractions to Web IDL
doesn’t help us, then we can define a custom interface binding for that
language.

(And the result of these discussions might be that better abstractions
in Web IDL are needed, such as a “dictionary” type rather than
individual getter/setter operations.)

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

I don’t think it should be an actual array, because you need behaviour
to be invoked when setting pixel data (repainting the actual <canvas>,
for example).

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

Well, no, we know what happens when people wrote in a more restricted
IDL language for Java-style languages and then applied them to JS.  I
think interfaces using the features of Web IDL that don’t exist in OMG
IDL have are mapping OK so far to Java, aside from a few issues like the
ones raised in this thread.  I would say though that Web API designers
are more aware of the issues though, and discussions like these help to
mitigate the problems.

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

Taking the one designed with JS in mind and applying it to other
langauges without thought is not good practice.  Designing with JS in
mind first, and then taking into account comments from those who do have
an interest in other language bindings (as I do with Java), especially
when they don’t constrain how the JS API behaves, seems to me to be a
reasonable approach.

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

Received on Thursday, 14 October 2010 21:56:31 UTC