Re: [heycam/webidl] Differences between "normal" platform objects and "normal" JavaScript classes (#226)

> Sorry, I meant instanceof, not typeof

Ah.  That's something that can be expressed in ES anyway using `@@hasInstance` (though typically is not, of course).

URL.createObjectURL and Promise.resolve are fundamentally different beasts: the former creates a _string_, while the latter creates a Promise.  I agree that statics that create an object of the type being defined _should_ be methods, to play nice with subclassing.  With that in mind, we _should_ change IDL to pass "this" to statics; if we don't have an existing issue on that, let's get one filed and just fix this.  That will allow specs to do the right thing here.  Whether we can change existing specs to the method semantics, I'm not sure.  :(

But I'm pretty sure this mostly (only?) affects statics that create an object of the type they're defined on.  I just looked (well, had our binding codegen look) through Gecko's IDL looking for such statics.  The full list is:

* IDBKeyRange.only
* IDBKeyRange.lowerBound
* IDBKeyRange.upperBound
* IDBKeyRange.upperBound
* IDBLocaleAwareKeyRange.bound
* Response.error
* Response.redirect

It's too bad no one raised this issue about statics when fetch's Response was being specified.  :(  IDB not raising it I'm not surprised by, of course; there weren't many ES-aware people involved in that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/226#issuecomment-258880052