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

On Tue, Jul 30, 2013 at 4:38 PM, Allen Wirfs-Brock
<allen@wirfs-brock.com> wrote:
>
> 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.

I take it you are basically asking why there is a need to have
'instanceof', or anything like it. Is that correct?

It's not entirely clear to me how you mean that the isDirectory
function would behave, or where it would live. Do you mean that we
would add a isDirectory() function on all Directory instances which
always return true?

That would mean that you write code like:

root.get("somename").then(function(result) {
  if ("isDirectory" in result) {
    // No need to actually call .isDirectory since it always returns true.
    ... it's a directory ...
  }
  else {
    ... it's a file ...
  }
});

This approach definitely works. Basically any time that you can have
objects of different types and want to find out what type of object
you have, you have to find some property that is unique for each type
that you want to check for.

The downside of this approach is that it's pretty fragile though. Any
time a property is added to existing classes, it risks creating a
situation where you are breaking type testing.

/ Jonas

Received on Wednesday, 31 July 2013 07:03:14 UTC