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
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
