types

Brendan Eich brendan at mozilla.org
Wed Aug 13 22:48:05 PDT 2008


On Aug 13, 2008, at 8:02 PM, Peter Michaux wrote:

> Reading the recent news about ES4 removing more of its old features
> and morphing into Harmony, it seems that the related ideas of classes,
> types and type checking are the surviving major new features.

It would be more accurate to say that members of the committee see  
value in some or all of:

1. Classes as higher-integrity factories than constructor functions  
that use closures for private variables;
1(a). possibly related by single or multiple inheritance, but in the  
simplest case with zero inheritance.
1(b) with this-bound (self-bound) methods, non-extensible instances,  
and other possibly differences from function constructors.

2. Like patterns, which are syntactic sugar for "shape tests",  
assertions about the structural type *at the present moment* of a  
given object.

3. Structural types, related by record width subtyping.

4. Optional type annotations, which provide both
4(a). a write barrier on a variable to prevent it from referring to  
an object that does not satisfy the types constraints;
4(b) a guarantee that the object denoted by the annotated variable  
will not mutate away from the type's constraints.

Opinions vary. I think it's fair to say some favor 1 (think  
Smalltalk) and possibly 3 (structural types do not require shared  
type definitions that are related by name; this can be winning in  
large systems involving multiple decoupled programmers), but are  
skeptical of 4.

Some (overlapping people here) point out the benefits of nominal  
types for security: nominal type annotations can act as auditors or  
guards that can't be bypassed from outside the lexical scope in which  
the type name is hidden; private nominal types bound the set of  
implementations that have to be inspected; generative nominal types  
can act as keys/nonces; nominal types make feasible information flow  
analyses that otherwise can't bound effects along all flows, so must  
leave the program counter tainted.

Most seem in favor of like patterns, from what I heard in Oslo. These  
are not types anyway, but convenient syntax for the kinds of shape- 
tests that are open-coded (sometimes with coverage gaps, sometimes  
skipped altogether) in modern Ajax libraries (isArrayLike, etc. --  
you call this "duck typing" below).

Like patterns and structural types could be thought of as JSON  
schemas. If you only need a spot-check that an object tree matches a  
structural pattern, use a like test or annotation. If you need the  
kind of monotonic guarantees listed in 4(a-b), then use structural  
types.


> Personally I've never quite understood why classes, types and
> type-checking have been such a fundamental part of the proposal. I've
> kept my fingers still about this for several reasons (mostly does my
> opinion even matter?) but all of this type business seems more trouble
> than it is worth to me (i.e. a daily JavaScript programmer.)

How large are the JS programs you write? What other programming  
languages do you use, and at what scale?

JS programmers write type checks and code with latent type systems in  
mind already. You do it. Doing this by hand, and often implicitly,  
can be pleasant at smaller scale, with no need for shorthands such as  
like patterns, or always/everywhere guarantees such as type  
annotations provide. Closures and constructors are enough for (1).

Scaling up across people, space, and time (even with only one  
programmer, time is a problem; one forgets latent types that the  
program relies on) leads many people to want more automation. YMMV.

Automation of type checks or shape tests does not mean static typing.  
Runtime checks and more advanced systems such as PLT-Scheme's  
Contracts can go a long way. But writing all the checks by hand is a  
tedious waste of programmer time, and it's costly enough that  
programmers tend not to do it. This seems good when prototyping, but  
it backfires at scale.


> Are these
> type-related features what the community of ECMAScript 3 programmers
> were really asking for emphatically years ago?

Some are, you've heard from Neil already.

But you're dismissing the other things than classes and types that I  
mentioned, which could be grouped into two categories:

1. Better modularity and integrity through name hiding. This includes  
the generative Name object idea, but also let as the new var for  
block scope (const and function in block too).

2. Conveniences: destructuring, spread-operator/rest-params,  
iterators/generators, expression closures.


> Is the community really
> asking for now with the surge of functional programming?

False dichotomy alert. Please look into functional programming more,  
including SML and OCaml; also TypedScheme and prior optionally-typed  
Scheme systems.

Not only is "functional programming" not antithetical to "type  
system" (even static type system), it covers a range of languages  
from Lisp to Dylan to JS to Scala. You use it as if it means one  
thing, "not typed", but that's false on both counts ("one thing" and  
"not typed").


> Looking in the new wiki page on types
>
> http://wiki.ecmascript.org/doku.php?id=harmony:types

First, let me say that this is just a sketch, not yet reviewed and  
not ready for prime time. I think Cormac would be happy to answer  
questions about it, although it may be better to wait a bit before  
diving in.

/be




More information about the Es-discuss mailing list