From Brendan Eich's JS2 design notes: 

Goals:

1. Support programming in the large with stronger types and naming.
2. Enable bootstrapping,

   self-hosting, and

   reflection.

3. Backward compatibility apart from a few simplifying changes.

 Non-Goals:

1. To become more like any other language (including Java!).
2. 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