Re: Should interfaces with values really be [NoInterfaceObject]?

--001a11c25d225fd8d9053aa26b7c
Content-Type: text/plain; charset=UTF-8

I think the logic for declaring them "No Interface Object" was that there
are never instances of these interfaces (they are all mix-ins implemented
by the different element interfaces), so there was no need to clutter up
the global namespace.

If it is a breaking change that is causing problems in implementations,
that would be a good argument for implementing them as global objects.  But
there are likely to be other propblems: the hierarchy of interfaces was
collapsed in many cases and names were changed.  If tests are detecting the
individual interface names, instead of the exposed methods and properties
on the element interfaces, this re-organization becomes a breaking change,
too.  In contrast, if they are all "No Interface Object" interfaces, then
the exact names and organization of the mix-in interfaces is safe to
change, because it's never exposed in the API.

Are you able to generate a full list of interfaces Firefox detects in test
cases?

~ABR

On 21 August 2016 at 15:07, Robert Longson <[email protected]> wrote:

> SVG 2 has this webidl definition of SVGZoomAndPan
>
>
> [NoInterfaceObject]
> interface *SVGZoomAndPan* {
>
>   // Zoom and Pan Types
>   const unsigned short SVG_ZOOMANDPAN_UNKNOWN <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__SVG_ZOOMANDPAN_UNKNOWN> = 0;
>   const unsigned short SVG_ZOOMANDPAN_DISABLE <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__SVG_ZOOMANDPAN_DISABLE> = 1;
>   const unsigned short SVG_ZOOMANDPAN_MAGNIFY <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__SVG_ZOOMANDPAN_MAGNIFY> = 2;
>
>   attribute unsigned short zoomAndPan <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__zoomAndPan>;
> };
>
> Without the NoInterfaceObject one could write something like
>
>    if (element.zoomAndPan == SVGZoomAndPan.SVG_ZOOMANDPAN_DISABLE)
>
> While one now has to write it as
>
>    if (element.zoomAndPan == SVGSVGElement.SVG_ZOOMANDPAN_DISABLE)
>
> The same applies to SVGUnitTypes. Do we mind about keeping backwards
> compatibility with any existing usages like this. We found when making
> this change that our own unit tests fail on SVGUnitTypes usage for
> instance.
>
> Robert
>
>

--001a11c25d225fd8d9053aa26b7c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think the logic for declaring them &quot;No Interface Ob=
ject&quot; was that there are never instances of these interfaces (they are=
 all mix-ins implemented by the different element interfaces), so there was=
 no need to clutter up the global namespace. =C2=A0<div><br></div><div>If i=
t is a breaking change that is causing problems in implementations, that wo=
uld be a good argument for implementing them as global objects.=C2=A0 But t=
here are likely to be other propblems: the hierarchy of interfaces was coll=
apsed in many cases and names were changed.=C2=A0 If tests are detecting th=
e individual interface names, instead of the exposed methods and properties=
 on the element interfaces, this re-organization becomes a breaking change,=
 too.=C2=A0 In contrast, if they are all &quot;No Interface Object&quot; in=
terfaces, then the exact names and organization of the mix-in interfaces is=
 safe to change, because it&#39;s never exposed in the API.</div><div><br><=
/div><div>Are you able to generate a full list of interfaces Firefox detect=
s in test cases?</div><div><br></div><div>~ABR</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On 21 August 2016 at 15:07, Robert=
 Longson <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><pre>SVG 2 has this webidl definition of SVG=
ZoomAndPan<br></pre><pre><br>[NoInterfaceObject]
interface <b>SVGZoomAndPan</b> {

  // Zoom and Pan Types
  const unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html#__s=
vg__SVGZoomAndPan__SVG_ZOOMANDPAN_UNKNOWN" target=3D"_blank">SVG_ZOOMANDPAN=
_UNKNOWN</a> =3D 0;
  const unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html#__s=
vg__SVGZoomAndPan__SVG_ZOOMANDPAN_DISABLE" target=3D"_blank">SVG_ZOOMANDPAN=
_DISABLE</a> =3D 1;
  const unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html#__s=
vg__SVGZoomAndPan__SVG_ZOOMANDPAN_MAGNIFY" target=3D"_blank">SVG_ZOOMANDPAN=
_MAGNIFY</a> =3D 2;

  attribute unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html=
#__svg__SVGZoomAndPan__zoomAndPan" target=3D"_blank">zoomAndPan</a>;
};<br><br></pre><pre>Without the NoInterfaceObject one could write somethin=
g like<br><br>   if (element.zoomAndPan =3D=3D SVGZoomAndPan.SVG_ZOOMANDPAN=
_<wbr>DISABLE)<br><br></pre><pre>While one now has to write it as <br><br> =
  if (element.zoomAndPan =3D=3D SVGSVGElement.SVG_ZOOMANDPAN_<wbr>DISABLE)<=
br><br></pre><pre>The same applies to SVGUnitTypes. Do we mind about keepin=
g backwards<br>compatibility with any existing usages like this. We found w=
hen making<br>this change that our own unit tests fail on SVGUnitTypes usag=
e for<br>instance.<span class=3D"HOEnZb"><font color=3D"#888888"><br></font=
></span></pre><span class=3D"HOEnZb"><font color=3D"#888888"><pre>Robert<br=
></pre></font></span></div>
</blockquote></div><br></div>

--001a11c25d225fd8d9053aa26b7c--