Such approach would Break the Web(tm), so it's not really an option anyway.
Reflect.type is really just a way to expose a concept inherent in the language which is already reified in the specification. It does not preclude future further type mechanisms that might prove more useful. "Don't let best be the enemy of better"! Cheers On Monday, 8 June 2015, Thaddee Tyl <[email protected]> wrote: > On Mon, Jun 8, 2015 at 4:38 PM, Nick Krempel <[email protected] > <javascript:;>> wrote: > > On 8 June 2015 at 15:05, Thaddee Tyl <[email protected] > <javascript:;>> wrote: > >> Ah! Good. I expected it to fail just like this: > >> > >> ```js > >> function Thing(){} > >> function SubThing(){} > >> SubThing.prototype = Object.create(Thing) // BUG: > >> Object.create(Thing.prototype) intended? > >> SubThing.prototype.constructor = Thing > >> Object(new SubThing) instanceof Thing // Then this would be true. > >> ``` > > That only fails because of the probable bug on the third line. > > You're right. Sorry. > > So, what is left? Is Reflect.type useful? Adding `Undefined` and > `Null` as types for which `Object(null) instanceof Null` etc. seems > unnecessary, since we'd use triple-equal comparison. > _______________________________________________ > es-discuss mailing list > [email protected] <javascript:;> > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
