Re: Notes from Monday's meeting with TC39 folks

Hi Maciej.

Maciej Stachowiak:
> Are these meetings getting announced in advance anywhere?

No, the first meeting just came out of replies to my call for meeting up
in the mega-crossposted thread.  Perhaps I should’ve then mentioned
concrete meetup plans on the list so that others could join, sorry.

I’m back in Melbourne now, but it was really just a chance to chat with
the TC39 folks while I was in the area.  I hope that the TPAC meetings
next month help move things along.

> How would you specify canvas's getImageData() with this approach? Or
> drawImage()? Seems like it is impossible to specify the interface
> correctly with the union type mechanism. It's one thing to
> "discourage", but if IDL can't specify the behavior of existing
> interfaces, then it will fail in its purpose.

Sorry I meant to mention drawImage() rather than getImageData() re the
poor design.  It’s always possible to widen the acceptable arguments (in
the extreme case to ‘in any args…’) and then restrict certain cases in
prose.  If it’s slightly inconvenient to treat the “same argument
position meaning the same thing” case for drawImage() then that’s OK by
me.  I don’t think the optional arguments coming in pairs is bad design,
though, so I would like for this to be possible to handle without going
to prose.

> >The thought is that there are few APIs where it makes sense to
> >distinguish null and "" when accepting a DOMString (getAttribute
> >being a
> >notable one).  But we will need to check.  There are two possibilities
> >on how ES values are coerced to DOMString by default:
> >
> > A) null is converted to ""
> >    anything else is converted using the String constructor
> >
> > B) everything is converted using the String constructor
> >
> >If an analysis shows that the former covers most cases (majority?
> >plurality?) then we would go with that and also not allow overriding
> >this in the IDL as you can do with [Null] (or [TreatNullAs], as it
> >became).
> 
> I think the default should be (A) but it should be possible to
> override for specific APIs, if needed for legacy behavior. This is
> my biggest problem with nullability as it exists in the current
> spec. The common case ("DOMString?") is longer and more
> funny-looking than the rare case ("DOMString").

I’m not sure that it is the common case to want to include null.  In
another mail today I pointed out copies of DOM specs’ IDL modified to
use nullable strings:

  http://dev.w3.org/2006/webapi/WebIDL/dom/

Now that’s just me going through the specs and seeing if null made sense
or was treated specially, but there are more instances of ‘DOMString’
there than ‘DOMString?’.

Probably someone should do better (some) testing, though.

…
> >Mark wondered whether there should be both [Supplemental] and the
> >‘implements’ statement, since both effectively augment the type
> >being supplemented (or the type on the LHS of the ‘implements’),
> >and might cause the same changes to an interface’s prototype object
> >(under a certain design of flattening multiple inheritance to single
> >inheritance prototype chains).
> 
> But the direction of relation is different. "implements" makes a
> new interface incorporate a pre-existing interface's methods and
> attributes. [Supplemental] allows an existing interface to be extended
> with new methods and attributes. When creating a new interface, you
> don't always have control of both ends of the relationship, as the two
> interfaces that you need to relate may be in different specs. It's
> useful to be able to do this in both directions.

‘implements’ does allow both directions, though.

> >I had some issues with [Supplemental] effectively allowing an
> >interface to lose members depending on which set of specs you
> >consider when generating a Java interface, which would cause binary
> >compatibility problems. (You want to only allow methods to be added
> >to an interface.)
> >
> >In Java you handle these cases with mixin interfaces, as is currently
> >done with various DOM specs (e.g. DocumentCSS, DocumentView). I think
> >it might be better to allow these to have unique interface names,
> >like DocumentCSS, but with an extended attribute that indicates
> >explicitly what prototype object is being supplemented with new
> >properties — maybe:
> >
> > [Supplemental]
> > Document implements DocumentCSS;
> >
> >or so.
> 
> Does retroactively adding a mixin preserve Java binary compatibility?

Yes, but ‘implements’ doesn’t change the declared superinterfaces in the
Java binding.

> >Those of us who were able to stay until the end of the meeting
> >(all but
> >Allen) were happy with a few initial recommendations, but I
> >unfortunately don’t have a note of them.  I believe they included:
> >
> > * Not allowing callable objects in future APIs
> 
> If it's allowed, it's allowed - at best we can say it SHOULD NOT be
> used in new APIs. I don't think it would be appropriate to
> grandfather in specific interfaces from other specs by name, and a
> requirement that doesn't name the specific interfaces would have no
> teeth.

Right.  So SHOULD NOT sounds appropriate.

> > * Not allowing inheritance DAGs (only trees)
> 
> Good idea in principle - do the IDL interfaces of SVG satisfy this
> condition?

I’ll have to check.  (Just to be clear, the tree would be the one rooted
at the derived interface, like SVGGElement, and not rooted at, say,
Node, which would imply that only single inheritance is allowed.)

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

Received on Thursday, 8 October 2009 11:07:01 UTC