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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
