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

Is it really worthwhile adding this surface area to all the APIs just to avoid the edge cases like HTMLElement.prototype instanceof Node? In what situation do we envision that kind of "false positive" being a problem?

> -----Original Message-----
> From: Travis Leithead [mailto:travis.leithead@microsoft.com]
> Sent: Saturday, July 20, 2013 01:37
> To: Boris Zbarsky; public-script-coord@w3.org
> Subject: RE: Maybe we should think about Interface.isInterface functions
> again
> 
> Well, we can start grass-roots-style with DOM4/5 and at least give the basic
> DOM structural objects this type of detection. If you then extend this to
> HTML, you're probably covering 90% of the use cases...
> 
> ________________________________________
> From: Boris Zbarsky <bzbarsky@MIT.EDU>
> Sent: Friday, July 19, 2013 8:46 PM
> To: public-script-coord@w3.org
> Subject: Maybe we should think about Interface.isInterface functions again
> 
> I've brought this up before: there is nothing in the DOM that allows reliably
> detecting DOM objects that implement a given interface.
> Something like Array.isArray or ArrayBuffer.isView as defined in ES.
> 
> Last time this came up we had sort of agreed to make instanceof kinda work
> for this by making it consider brands in addition to proto chains, but this has a
> problem: HTMLElement.prototype instanceof Node is very much true (and
> web pages depend on this behavior, as I recall) but HTMLElement.prototype
> is most definitely not something that would pass a sane isNode() check...
> 
> Now I suppose spec authors could add such things ad-hoc (e.g. add a "static
> boolean isNode(any arg)" on Node and define it in prose to return true if and
> only if arg is a Node).  But maybe there should be a way to either express this
> in IDL or the default behavior should be to have such methods?
> 
> -Boris
> 
> 
> 
> 
> 
> 
>

Received on Saturday, 20 July 2013 06:15:29 UTC