W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

RE: Maybe we should think about Interface.isInterface functions again

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Wed, 7 Aug 2013 17:13:14 +0000
To: Domenic Denicola <domenic@domenicdenicola.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <22ace18cf7aa4f808e6f128697668a9c@BLUPR03MB245.namprd03.prod.outlook.com>
>The question is, how can we do that, without `Element.isElement`? A test like `x instanceof Element` does not work, because both `Element.prototype` and `HTMLElement.prototype` pass this test, but are not "really" elements

I think you have a legitimate concern, but I did want to point out that Element.prototype instanceof Element is false (not true). However, HTMLElement.prototype instanceof Element is true. To tell an instance from a prototype object you could always check for a 'contructor' own property on the instance (if constructor exists, then you've got a prototype). You could also just test to see if the object you're dealing with "acts like an element" (duck-typing). E.g., if you need to call querySelector on the instance, then just see if there is such a method and invoke it--this helps your own implementation of something like 'findAll' be generic like the other Array methods.

-----Original Message-----
From: Domenic Denicola [mailto:domenic@domenicdenicola.com] 
Sent: Wednesday, August 7, 2013 7:56 AM
To: Allen Wirfs-Brock; Boris Zbarsky
Cc: Travis Leithead; public-script-coord@w3.org
Subject: RE: Maybe we should think about Interface.isInterface functions again

Allen, I have a case that I would appreciate your input on. At first glance it seems like `Interface.isInterface` is exactly what we need, but I dislike the idea of adding such methods everywhere, so any alternative would be appreciated.

Consider a hypothetical "Elements" class, subclassing array, and meant to hold `Element`s. You can see a rough definition [in this gist][1].

For ease of use it allows non-`Element`s to be added, e.g. via `elementsInstance.push(5)`. There's a few reasons for this:

- Overriding all the array methods to add type-checking is not fun.
- Even if you did that, `Array.prototype.push.call(elementsInstance, 5)` would still work, so you end up needing to fall back to a proxy, losing most of the benefits of subclassing `Array` in the first place.
- All that aside, it's really convenient to be able to easily do things like `elementsInstance.map(el => el.tagName)` and treat that as an array, just by not using any of the special `Elements`-only subclass methods. You can even see an example of such usage in the gist.

I am assuming this is good design; if you think otherwise I guess that's a different conversation (feel free to fork the thread).

Anyway, with that in place: certain methods of `Elements`, e.g. `Elements.prototype.findAll`, want to ignore any non-`Element` members. The question is, how can we do that, without `Element.isElement`? A test like `x instanceof Element` does not work, because both `Element.prototype` and `HTMLElement.prototype` pass this test, but are not "really" elements; you can't do anything useful with them, e.g. calling `querySelectorAll` just blows up.

Would love your feedback on this case, which feels like a more general case of how the web platform uses branding.

[1]: https://gist.github.com/domenic/5864658
Received on Wednesday, 7 August 2013 17:15:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC