W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: [geometry] Dictionary argument for DOMQuad constructor

From: Robert O'Callahan <robert@ocallahan.org>
Date: Sat, 28 Mar 2015 10:33:47 +1300
Message-ID: <CAOp6jLZ5=it9Y54tTuon4Wyvhih+xwWW9s8eB7QUwzUc4yxhTA@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: "public-fx@w3.org" <public-fx@w3.org>, Domenic Denicola <d@domenic.me>, Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Mar 27, 2015 at 11:17 PM, Simon Pieters <simonp@opera.com> wrote:

> On Thu, 26 Mar 2015 22:10:08 +0100, Robert O'Callahan <
> robert@ocallahan.org> wrote:
>  On Fri, Mar 27, 2015 at 10:02 AM, Simon Pieters <simonp@opera.com> wrote:
>>  It is useful to be able to use a straight JS object as a rect. I think it
>>> would be good for Web developers to consistently support dictionary types
>>> instead of supporting them in some places but require an object of the
>>> proper interface in other places.
>> 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? 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'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.

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


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.

oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
otohoeo ofoioroeo ooofo ohoeololo.
Received on Friday, 27 March 2015 21:34:16 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 March 2015 21:34:18 UTC