> Axel Rauschmayer wrote: >>> I agree with Tom, "object" is the best choice if we are to avoid extending >>> typeof's codomain. If we choose to extend, then your best case made above >>> arguess for "symbol", not "string". >> >> I’ve been wondering: instead of fixing typeof, wouldn’t it be simpler to >> extend instanceof, by introducing new types: >> >> - ReferenceType: to check whether a value is an object. Currently, objects >> such as Object.create(null) and Object.prototype are objects that are not >> instanceof Object. > > This doesn't work with value objects, and anyway doesn't work by testing > proto-chain membership starting from RHS.prototype where RHS is the > constructor function. > >> - ValueType: for primitives and possibly future value objects. >> - PrimitiveBoolean: for primitive booleans, same as typeof x === 'boolean' > > Again, we cannot inserte more prototypes on existing proto-chains. > >> - etc. >> >> Should there ever be guards in the future, instanceof MyGuard would also >> make sense. > If you are not using the proto-chain, then what? What's the underlying theory > for extending instanceof?
The idea would be to not use the proto chain (which would be odd for primitive values, anyway), to make these “pseudo-types” special. > Compatibility concerns make this a non-starter, IMHO. We'd do better to keep > instanceof simple and extend typeof. IE already has extra typeof results so > developers have to beware. Extending instanceof would result in something that is more consistent. It would allow less experienced programmers to ignore the difference between primitives and objects (which you *almost* can now in JavaScript, in stark contrast to, say, Java). Axel -- Dr. Axel Rauschmayer [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
