> One of the first complications with types is typeof's behavior. All of the above types would return their string conversion including bool. (In my experience "boolean" is seen as verbose among C++ and C# developers. Breaking this part of Java's influence probably wouldn't hurt to preserve consistency for the future).
I can't see typeof changing at all. "Verbose" output doesn't seem like a problem that is worth breaking backwards-compatibility to solve. We've seen a new pattern in ES5 and continued now with ES2015: - Array.isArray() - Number.isNumber() - Object.isObject() - etc... Perhaps this pattern just needs to be continued for all types, including the TypedArrays (if not already being considered). I personally like this pattern because it doesn't change typeof, and it provides an less-verbose alternative, and it is able to be polyfilled because it's an API addition and not a syntax change. Other than this, I like the idea of optional static typing. I am a little ambivalent about the syntax. I can't decide if it literally should just be decorators, or if it deserves something more special. Perhaps all we really need here is the ability to name decorators using Symbols. This way, ECMA / TC39 can use real data over time to add type decorator Symbols for the 90% case without conflicting with future code. By virtue of being built-in Symbol-named decorators, they should still be able to natively-optimised and statically-analysed.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
