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: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Tue, 30 Jul 2013 16:38:18 -0700
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Travis Leithead <travis.leithead@microsoft.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-Id: <CA8CAC15-5124-48B3-9497-B38694B80D35@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

On Jul 20, 2013, at 5:25 AM, Boris Zbarsky wrote:

> On 7/20/13 2:14 AM, Domenic Denicola wrote:
>> 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?
> https://twitter.com/kuvos/status/348019487120957440 and following discussion has a description of such a situation arising in real-life code: the code wants to test for ownerDocument being non-null, but it only wants to do this on Node objects, of course.  And HTMLElement.prototype is one of the objects it ends up being passed, for whatever reason...
> -Boris

It would be really useful to see some more complete examples of where this is sort of dynamic discrimination is actually needed in application code. This style of type testing has a smell to it and it isn't clear to me whether the use cases you see arise from poorly designed APIs or whether you think there are situations where it makes sense in a good design.  

Jonas, mentioned the filesystem API but it isn't clear to me why an instance side isDirectory method wouldn't suffice for what I imagine is this use case.

Received on Tuesday, 30 July 2013 23:38:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:17 UTC