types

Peter Michaux petermichaux at gmail.com
Wed Aug 13 23:37:46 PDT 2008


On Wed, Aug 13, 2008 at 10:48 PM, Brendan Eich <brendan at mozilla.org> wrote:
> 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.

[snip]

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

I'm not sure if these two questions are rhetorical or not but anyway...

A single web page can be somewhere up to 10K lines which is reasonably
hefty page given JavaScript is not very verbose.

Just out of curiosity, are there many folks on the committee that
write JavaScript applications? I ask that question with zero snark
factor. I have the impression the majority of members are language
implementers and that may be a completely unfounded impression.

I don't use any other language at a larger scale partly because
JavaScript is the language in the browser and that is where I
currently work. Some spare time is spent in Lisp/Scheme.

I often wonder if it is necessary that ECMAScript is a language which
"covers all bases" and it good at all scales. We have plenty of
languages that already try to do that (and don't.)

> 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.

I'm not arguing against type annotations with this comment but I don't
see much difference in terms of remembering to have type checks
between writing

function(a) {isInt(a); ...

and

function(a:int) { ...

I believe that a:int actually is intended to assign a type to the
variable a and the isInt only checks the contents of a at the moment.
I'd rather the second be sugar for the former and the variable is not
typed at all.

> 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.

Yes these generally seem like good features.


>> Is the community really
>> asking for now with the surge of functional programming?
>
> False dichotomy alert.

[snip]

As I mentioned in my reply to Neil, my statements were misleading.
Having types in a functional language is clearly possible and even
common. I don't have anything against objects having types.

Your points 1-4 above and the differences of opinion and preferences
seem to be a big obstacle to overcome in a committee by consensus.

Peter



More information about the Es-discuss mailing list