Should interfaces with values really be [NoInterfaceObject]?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Should interfaces with values really be [NoInterfaceObject]?

Robert Longson
SVG 2 has this webidl definition of SVGZoomAndPan

[NoInterfaceObject] interface SVGZoomAndPan { // Zoom and Pan Types const unsigned short SVG_ZOOMANDPAN_UNKNOWN = 0; const unsigned short SVG_ZOOMANDPAN_DISABLE = 1; const unsigned short SVG_ZOOMANDPAN_MAGNIFY = 2; attribute unsigned short 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
Reply | Threaded
Open this post in threaded view
|

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

Amelia Bellamy-Royds
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 <[hidden email]> wrote:
SVG 2 has this webidl definition of SVGZoomAndPan

[NoInterfaceObject] interface SVGZoomAndPan { // Zoom and Pan Types const unsigned short SVG_ZOOMANDPAN_UNKNOWN = 0; const unsigned short SVG_ZOOMANDPAN_DISABLE = 1; const unsigned short SVG_ZOOMANDPAN_MAGNIFY = 2; attribute unsigned short 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

Reply | Threaded
Open this post in threaded view
|

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

Robert Longson
SVG 1.1 did permit instances of these interfaces and existing UAs support this (https://bugzilla.mozilla.org/show_bug.cgi?id=1241898#c6).

Currently Firefox does not have either SVGUnitTypes and SVGZoomAndPan as [NoInterfaceObject].

Robert.

On 22 August 2016 at 06:35, Amelia Bellamy-Royds <[hidden email]> wrote:
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 <[hidden email]> wrote:
SVG 2 has this webidl definition of SVGZoomAndPan

[NoInterfaceObject] interface SVGZoomAndPan { // Zoom and Pan Types const unsigned short SVG_ZOOMANDPAN_UNKNOWN = 0; const unsigned short SVG_ZOOMANDPAN_DISABLE = 1; const unsigned short SVG_ZOOMANDPAN_MAGNIFY = 2; attribute unsigned short 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