Re: [geometry] Dictionary argument for DOMQuad constructor

On Fri, 27 Mar 2015 22:33:47 +0100, Robert O'Callahan  
<robert@ocallahan.org> wrote:

>>> Hmm. If we apply that consistency strictly, then we're not going to use
>>> interface types as parameters anywhere, correct?
>>>
>>
>> Yes.
>>
>
> What do you mean by "anywhere" then?

I mean "yes" as in "correct".

> Any DOMRect or DOMRectReadOnly
> parameter on any method of any interface? What about other parameter  
> types?
> Are we going to extend this approach to every interface that can be fully
> initialized from an Init dictionary?

I suggest we do this for everything in the Geometry API spec plus the  
GeometryUtils part of CSSOM View.

Looking around a bit for other things where this issue could apply, I only  
find the following, from the HTML spec:

createImageBitmap(obj); // current spec with overloading
vs
ImageBitmap.fromImageData(obj) // aligned with Dominic's proposal; obj can  
be ImageData or ImageDataInit

https://html.spec.whatwg.org/multipage/webappapis.html#images

I don't have a strong opinion about that API. It seems it's not shipped  
yet.

>>  I'm not sure we should do that. It makes overloading impossible unless  
>> we
>>> make large changes to WebIDL.
>>>
>>
>> The spec currently only uses overloading in the constructors, and the
>> proposal here is to remove the overloading in favor of static methods.
>>
>
> That's true in this case, but maybe not depending on the scope of the
> consistency you want to enforce.

Since the key aspect of Dominic's proposal is "avoid overloading", it  
seems like a non-issue that it makes overloading impossible with the  
current WebIDL spec.

I suppose the "risk" here is that we set a pattern that other new APIs  
will be copying. Alternatively, that we keep changing how we design APIs  
over time instead of matching the legacy which results in the Web platform  
being largely inconsistent with itself. This is already the case, though.  
My aim here is more internal consistency for one API, and reduce  
confusion/surprises for Web developers.

As for already-existing APIs, Event constructors already use dictionaries  
where it works to pass in an actual Event object instead. Blob and File  
constructors similarly use dictionaries with the same shape as Blob and  
File for the *PropertyBag argument. I don't know if it was deliberate in  
these cases to enable doing so.


>>  It also has performance implications: passing
>>> a DOMRectReadOnly as a DOMRectInit parameter naively requires  
>>> unpacking to
>>> a JS object and then repacking to a DOMRectInit. We could optimize that
>>> but
>>> it's a significant amount of work that nobody's done yet AFAIK.
>>>
>>
>> This applies equally to DOMPointInit, right?
>>
>
> Yes.
>
> The current state of the spec is broken (not valid WebIDL). How about I  
> try
>> to fix it to be more like what I think is more consistent, which in some
>> cases is not compatible with what is implemented in Gecko, so we can
>> compare it with the previous version of the spec? I can add an issue to  
>> the
>> spec saying that the old version is implemented in Gecko and the new
>> version is experimental and might not stick.
>
>
> Sure, that sounds good.

OK, thanks.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 31 March 2015 11:55:00 UTC