On Fri, 27 Mar 2015 22:33:47 +0100, Robert O'Callahan
<[email protected]> 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
