From Brendan Eich's JS2 design notes :
Goals:
- Support programming in the large with stronger types and naming.
- Enable bootstrapping , self-hosting , and reflection .
- Backward compatibility apart from a few simplifying changes.
Non-Goals:
- To become more like any other language (including Java!).
- To be more easily optimized than the current language.
Type operators and type annotations
Type annotations are optional.
To support strict options that require every declaration to be annotated,
*
may be used for ⊤ (the top type), e.g.
var v is *
, which is equivalent to
var v
.
Note that
*
is used differently for E4X, but its meaning as
⊤ is unambiguous in type operator and annotation right operand contexts.
In a nutshell,
is t
annotations insist on type
t
and defend against null and undefined (no more "foo has no properties" errors;
with static analysis, an error that can't be avoided at runtime can even be
reported at compile time).
as t
annotations enforce (
is t
)-or-null invariance.
And
to t
annotations convert according to cleaner,
class-extensible rules.
[...]
Given types, you can assert (is), coerce (as), or convert (to). Conversion alone is not enough, since it either leaves null unconverted, which is a "foo has no properties" hazard that one should be able to assert against with an annotated declaration; or conversion changes, e.g., null to String "null", which may be acceptable with dynamic types only (Edition 3 and earlier), but which is wrong with asserting and coercing annotations such as "var str is String" and "var strOrNull as String".
Since "to" converts rather than asserts or coerces, it is not sufficient as the only kind of type annotation.
Hence the symmetry between the type operators and annotations. Failing to provide an annotation for a type operator gratuitously forces programmers to hand-code constraints, instead of letting the type system do the work.
10.11.2005, 17:32