Re: Notes from Monday's meeting with TC39 folks

On Oct 8, 2009, at 4:06 AM, Cameron McCormack wrote:

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

Me too!

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

It's possible, but explaining interface details like that (including  
what exceptions are thrown?) is something that Web IDL is supposed to  
make easier. I think the purely theoretical benefit of using union  
arguments is outweighed by the practical cost of describing interface  
details in prose. If there's extra argument type constraints that are  
purely in prose, then to be able to use Web IDL directly in WebKit,  
we'll have to invent some form of annotation in the IDL to describe  
those constraints (to autogenerate the type conversion and to generate  
bindings for languages like ObjC or C++ where we need real overloads,  
but only for the valid combinations). So there is a cost both for use  
of Web IDL by specs, and for use by implementations to generate  
bindings automatically from Web IDL.

> 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 drawImage() case is optional arguments in pairs, but for  
createImageData(), the types allowed are different depending on the  
number of arguments. Taking either an object or two numbers that give  
coordinates seems like a reasonable pattern to me, one I can imagine  
wanting to use in other places. A method taking a single object  
parameter or several string parameters was suggested for Selectors  
API, and also seems like a reasonable design choice.

Note: I like the idea of optional arguments and union types in theory,  
they seem more succinct, but it would be good to be able to represent  
slightly more complicated constraints on allowed types directly.

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

Yeah, I'm not sure those IDL files reflect existing implementations  
correctly. Note: WebKit is less aggressive than e.g. Gecko about the  
places where null is treated as empty string, partly because we  
inherited the wrong default from KHTML and have only gradually fixed  
various places over time. I suspect Gecko's behavior is more  
compatible, because many places where we originally got it wrong  
turned into bug reports. We just haven't gone through to make all the  
edge cases match other browsers yet.

>
> …
>>> 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 see. I guess the only inconvenience currently is that you have to  
name the interface to be added and that it causes the weird mixin  
prototype behavior. In WebKit, we'll likely combine all [Supplemental]  
interfaces into the main interface. It would be nice if specs had a  
mechanism that is observationally equivalent to writing it all as one  
interface, at least for purposes of the ECMAScript binding.

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

How does it work in the Java binding? I suspect using 'implements'  
instead of '[Supplemental]' in HTML5 where it extends its own  
interfaces would be bad for Java, depending on the implementation  
strategy.
>
>>> * 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.)

Right - what I'm concerned about is diamond inheritence patterns. I  
could not tell with a cursory examination if SVG had any.

Regards,
Maciej