Web IDL hasInstance behavior

[Domenic Denicola]

Apparently for a long time Web IDL has specified special behavior for instanceof on platform objects.

Boris is interested in updating the spec for ES6 which means using `Symbol.hasInstance`. This is a similar change to the recent changes to use `Symbol.toStringTag`.

However, I am unsure we want to support having special hasInstance behavior at all. Nobody currently implements this besides Firefox. The motivation seems to be to provide some kind of branding mechanism, but in my opinion overriding instanceof is probably not the right way to do that.

It sounds like the decision was made before my time though, in threads that are old enough that Boris doesn't really remember them. So maybe it would be bad to walk back on that consensus? But I am unsure whether there was really ever consensus. It looks to me like the discussion was had at https://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/0001.html and did not have any involvement from Chrome engineers.

I thought it would be worth getting the binding team's thoughts. I think this behavior is a mistake but I am not prepared to fight against it on my own. If the binding team is OK with implementing it, or plans to not implement it, it would be good to get one of you to weigh in on https://github.com/heycam/webidl/issues/129.

[Kentaro Hara]

+verwast +jochen

--

Kentaro Hara, Tokyo, Japan

[Jochen Eisinger]

+adamk

[Toon Verwaest]

+bmeurer, +mvstanton who implemented @@hasInstance in v8 (keeping instanceof fast exactly by assuming that nobody uses @@hasInstance...)

[Adam Klein]

As Toon points out, this would have significant performance implications for instanceof, at least in v8's current implementation.

What would you propose as an alternative branding mechanism? I don't doubt that this is a problem programmers have.

[Domenic Denicola]

I guess I could see a few possibilities worth discussing:

• isPlatformObject(obj, "TypeName"), e.g. isPlatformObject(obj, "Node")
  
• TypeName.isTypeName(obj), e.g. Node.isNode(obj)
• TypeName.isInstance(obj), e.g. Node.isInstance(obj)

[Yuki Shiino]

Let me ask a silly question; what's good with Symbol.hasInstance?

If Symbol.hasInstance were supported, it seems that user JavaScript can pretend to be an instance of an interface/class that is not the actual type.  What benefits are there?

Simply I don't understand why we'd like to introduce Symbol.hasInstance.

Cheers,

Yuki Shiino

[Adam Klein]

While those are all reasonable questions, V8 does support Symbol.hasInstance, as part of our implementation of ES6 in general.

So this thread is really about whether WebIDL should utilize Symbol.hasInstance.

Note that even without Symbol.hasInstance, "instanceof" in JS is a pretty "weak" relationship: it basically asserts a few things about the prototype chain.

[Toon Verwaest]

If hasInstance becomes a broadly used feature, main instanceof performance will suffer and we'll need a different strategy to make sure that users of @@hasInstance aren't on the slow path by default.

[esp...@google.com]

I'd really rather we didn't do this and just removed it from the spec, it's been years and no browser except Firefox does this, and they have a radically different binding system which makes it perhaps easier.

It's also of questionable value as you note. It's very strange to me that doing (e instanceof HTMLDivElement) might be true, but if you had modified HTMLDivElement.prototype to have new methods they'd be missing.

I'm fine providing some kind of Platform.isInstance like facility if authors actually want that, though I've never heard anyone ask for it (literally the only compliant I've ever heard was for Array, and Array.isArray fixed that.)