Lambda the Ultimate

Actually, it's not just classes but strong typing as well. I work closely with some Flash developers who are making the switch from ActionScript 1 to AS 2. The language is ECMA Script based so it's essentially the same as Javascript.

It's a bit of a shame to see the expressivity of a language built for a certain purpose (web scripting, animation) get wrung out in favour of the mittens and gloves "Everything must look like Java" school of thought.

Apart from a couple of extra instructions, the bytecode underneath AS2 is the same. The strong typing is only enforced by the compiler, so AS1 and AS2 binaries can co-exist.

The phrase "strong typing" doesn't really mean much, at least not consistently (for example, see PLAI, Chapter 30). I'm not sure what aspect you object to, but in this case what they mean is a strange little runtime check that's extremely limited. In fact, it guarantees so little of interest that I can't imagine what it would be used for. (That's not entirely meant as a blow-off; but I don't know.)

The property that it allows you to "enforce"--aside from the blatant (though admitted) lack of soundness--is totally the wrong property! The class of an object is not its type in Javascript! This is the same situation as Java, and it's the same consistent misunderstanding: interfaces relate to the types of objects, whereas classes are particular implementations. The identification of classes with types is a big mistake.

This may sound academic, but there are already lots of examples in real-world Javascript where this is important. For example, there are several classes that behave like arrays in JS: the arguments object, instances of the Array object, instances of the NodeList object in Mozilla, instances of the hidden object that acts like NodeList in IE... For each of these classes, the important feature is that they have a length property and properties "0" .. "length - 1", so they can be iterated by a for loop. So there's an implicit Iterable interface that each of these objects implements, and that's its type. Whether it's an Array or a NodeList is unimportant.

Similarly, all the official DHTML API documentation is given by interface (e.g. here, here, or here, but different browsers use differently named prototypes to implement them. In IE, you don't even have access to the prototype. But there's no way to test an object for its interface, there's no way to guarantee membership, nothing; it's just a programmer's promise. If you want a type system, that's where it should be.

Are there any languages that use only the interface as an object's type? It seems that C++ templates might be kind of close to that, but it isn't perfect. For many years I've toyed with the idea of a language that only had interface as a basis for data type, but I haven't done much with it. I haven't even researched it. It is just one of those ideas in mind that makes sense but I always seem to forget to look into. :)

...almost all functional languages do. That is, they are "structurally typed" (operations will work on any data that has the right "shape") vs. "nominally typed" (type relationships are explicitly defined by the programmer). Most popular languages are nominally typed. Most "esoteric, functional" languages are structurally typed. You can do some really interesting things in O'Caml, combining modules, functors, classes, objects, parametric polymorphism, etc. once you really understand this. For example, you can say "this parameter can be anything that implements the 'print' method" without concern for whether the objects passed have an inheritance relationship with each other or not. It's very nice.

Implementation inheritance is a convenience mechanism. Type inheritance is more along the lines of java interfaces. As the Sather folks say:

In most object-oriented languages inheritance both defines the subtype relation and causes the descendant to use an implementation provided by the ancestor. These are quite different notions and confounding them often causes semantic problems. For example, one reason why Eiffel's type system is not statically checkable is that it mandates "covariant" conformance for routine argument types (Meyer, 1992). This means that a routine in a descendant must have argument types which are subtypes of the corresponding argument types in the ancestor. Because of this choice, the compiler cannot ensure argument expressions conform to the argument type of the called routine at compile time. In Sather, inheritance from abstract classes defines subtyping while inheritance from other classes is used solely for implementation inheritance. This allows Sather to use the statically type-safe contravariant rule for routine argument conformance.

If I recall correctly, the latest Eiffel standard (or draft) added, side by side with the classical multiple inheritance, a mechanism that allows non conforming inheritance, where a superclass is inherited just for implementation's sake.
See here (unavailable ATM, google html cache here)

In strongtalk there are only interface ("protocol") types, no class types. Each class introduces a protocol which can be used in type expressions and which other classes can implement without necessarily inheriting the implementation of the class.

"Strongtalk separates types from classes. The type hierarchy is defined using protocols. A protocol is a collection of message selectors and their associated signatures. A message signature specifies the types of a message's arguments and its return type. Every class C automatically induces a protocol, known as C protocol. In type expressions, no ambiguity can arise as to whether a name denotes a class or a protocol, so we elide the selector protocol, and refer to C protocol as just C."

Are there any languages that use only the interface as an object's type?

The obvious answer here is Objective Caml. It is strongly typed with fully structural object types that are completely independent from the class hierarchy (and in fact automatically inferred). In fact, objects need not belong to a class at all, classes are merely convenient factories.

IMO, C++ templates do not count at all, because they do not have any expressible notion of "interface" (until the arrival of concepts, maybe).

BTW, I wrote an opensource ActionScript2 compiler named MTASC and we're using in-house language called MotionTypes for Flash dev which add functional and anonymous types, type inference and structural subtyping. It generates directly Flash bytecode and works like a charm.

Hi, can you describe this language in more detail, in its own LtU post?

have done some getting acquainted work with MTASC recently, like it quite a bit.

It's not public yet so right now I'm not sure people want to ear about it if they can't play with it, but feel free to mail me privately your questions if you have.

It wouldn't hurt to describe the project on LtU anyway -- people would be glad to hear about it. It's up to you, of course, but I don't think there's any harm in describing the project informally before you've released.

First, you clearly did not read the article. Section 4.2 "Strong Dynamic Typing" starts out:

JavaScript 2.0 is strongly typed — type declarations are enforced. On the other hand, JavaScript 2.0 is not statically typed — the compiler does not verify that type errors cannot occur at run time.

The paper then gives a couple of examples which illustrate that type declarations are checked dynamically.

Second, although obviously JS was intended for web scripting (and AS for animation), there is really nothing in Core JavaScript 1.5 which has anything to do with web scripting (or animation). In other words, even for JS, web scripting is a library issue.

Third, "Java" != "static typing".

Fourth, even if you think that statically typed languages are less expressive than untyped ones, it is impossible to argue that adding the ability to check things statically to an untyped language would somehow make it less expressive.

Fifth, statically typed languages are evidently more statically expressive than untyped languages.

Sixth, well... I won't go on.

class A {
static private {
const x;
const y;
const z;
}
function f() {}
}

did that make you feel better?

and it didn't help

Brendan posted the slides he used at XTech: JavaScript 2 and the Future of the Web. The slides are in the S5 format. I found it easier to read the plain-text version:

$ links -dump http://developer.mozilla.org/presentations/xtech2006/javascript/

A couple of quotes:

• Netscape's "JavaScript 2" / "ECMAScript Edition 4" proposals were too different from JS1
• JS2 implementations too long in coming
• Yet old proposals have high search rank

On the cost of closures:

Measure the cost of private members via closures:

 function Point(x, y) {
   return {
     getX: function () { return x },
     getY: function () { return y }
   }
 }

 for (var i = 0, a = []; i 

What's the cost?

Over 3x slower and 3x the memory use of

 function Point1(x, y) {
   this.x = x
   this.y = y
 }