Re: Notes from Monday's meeting with TC39 folks

Maciej Stachowiak:
> 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.

OK I agree, it doesn’t seem like a bad pattern to overload like this for
createImageData().  I wonder if union types plus a much more restricted
form of overloading would work (if that restricted form of overloading
reduced the complexity of the overload resolution stuff currently in the
spec).

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

Yes the union types seem particularly appropriate for particular kinds
of overloading (like the HTMLImageElement vs HTMLVideoElement in the
first argument to drawImage()).

Cameron McCormack:
> > ‘implements’ does allow both directions, though.

Maciej Stachowiak:
> 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.

Yes, I think that’d be the solution.  I think putting [Supplemental] on
the ‘implements’ statement makes sense because that’s where mixin
interfaces are going to be specified.  In fact, it might make sense for
‘implements’ statements to always imply [Supplemental] and to mix in
their properties to the LHS interface’s prototype object.

Maciej Stachowiak:
> > > 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.

In the Java binding it doesn’t affect the LHS interface at all.  It just
means that all objects implementing the LHS will implement the RHS
interface.  (And so casting is required to get from Document to
DocumentCSS, for example.)

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

Received on Thursday, 8 October 2009 21:58:58 UTC