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 14:56:13 UTC