These notes cover:

ECMA TC39 meetings 3rd May 2000

Mountain View, 3rd May 2000, hosted by Netscape

Morning Disucssion

Deliverables & Scheduling

Herman brought up issues regarding deliverables and scheduling. Is it realistic to have a draft of the standard by the end of the year? Features may have to be dropped. Waldemar said that we have until June of 2001 to finalize this. Herman suggested we need milestones, as Microsoft is concerned about progress. Herman cited the need to have a delivery mechanism, and Waldemar's current document doesn't follow the ECMA3 standard, so it will be difficult to generate a delta document from E3. A delta document is crucial to reason about backward compatibility constraints.

Waldemar stated that we want to recast old language features in terms of new features, so a delta document is premature. Herman said that lots of work will be required to bridge the old with the new.

Chris asked how do we proceed if we can't agree on the language features. Dave suggested that we need to list what we do agree on. Waldemar agreed that we need to reach a consensus first. Herman replied that the specification and implementation efforts are similar.

Action: Waldemar & Herman should collaborate on an informal document not unlike the regular expression document.

Language Execution Model

Herman expressed a fundamental disagreement with the language execution model in Waldemar's proposal. Need to ensure that the language is easy to explain and admits a small implementation. Chris questioned whether a dumb compiler can work, and whether type information can just be ignored (Dollin principle).

Herman said that the aims of a dynamic execution model can be cast as conditional compilation and generics. Waldemar replied that this may be true when a compiler sees an entire program at once, but that web pages with incremental page loading can have multiple script tags, and execution needs to begin before entire program has been seen. Herman agrees that late binding must be preserved, and stated that classes defined by later scripts can't be referenced by earlier scripts. Chris asked about circularity and Herman said that forward declaration of types will be necessary to resolve.

Herman said that MS' JScript has a preprocessor, which can be used to handle conditional compilation needs. Templates/generics can handle, but not require types to be other than compile time consants. A dynamic execution will be difficult for MS to implement. Waldemar proposed a subset of the dynamic execution model, in which type expressions must be compile time constants. This proposal was agreed upon. Chris explicitly stated that E4 will require all names in type expressions to denote constant values.

Expandos / Dynamically Added Properties

Herman:

JScript supports the syntax

foo(x) = 42 => foo.defaultMethod(x, 42)

b.x is equivalent to b["x"]

Waldemar: We'll need to modify this equivalence for private properties.

Herman: Want to abolish this equivalence completely. Only expando properties should be accessible using [] notation.

Waldemar: We still need to be able to use new objects from old code.

Dynamic Property Lookup

Should declared class properties be enumerable or eligible for dynamic lookup? If they are enumerable, then they must be accessible via [].

Waldemar suggested adding dynamic properties is equivalent to dynamic subclassing, like prototype inheritance.

Point: final classes can have no dynamic properties added (Netscape) vs. declaring classes to be "expandos" (MS) thus allowing dynamic properties to be added. Different default views.

Action: we need to have a consensus about the rules of dynamic lookup ([]).

Versioning

Waldemar discussed the unintended override problem. Say we have a class C, with a member a, and another class D inherits from C, and adds a new member, b.

// C.js
package P1;
class C {
   var a;
}
// D.js
package P2;
import P1;
class D extends C {
   var b;
};
// x.js
var x = new D;
x.b;

What happens if the class C is evolved and adds a new member, also called b? In the absence of versioning, D has unintentionally overridden C.b.

class C {
   var a;
   var b;
}

We want to be able to solve this problem. Existing subclasses of C should be minimally impacted, as well as clients.

Versioning solution. Class C, when it adds the new member b, adds it using a namespace declaration.

package P1;
namespace NS;
class C {
   var a;
   NS var b;
}
// x.js
import P2;
var x = new D;
x.b; // b comes from D, no ambiguity.

Herman objects to this as a complex solution, too hard to explain to users.

Waldemar discusses "a.b", which means lookup the b property in the object denoted by a. In E3, the static type of a is irrelevant. We want subclasses to be subtypes. Given the above example, anywhere a C can be used, a D should also be useable. Object is the common base class of all classes.

class C : Object {
   b
}
class D : C {
   q
}
a = new D;
// a.b sees C::b.
var a : C = new D;
// same result

So for Object/Any types, a.b is equivalent to a["b"], e.g. dynamic lookup is used when type of object value is Object/Any. Should we special case Object/Any such that using operator . is equivalent to []?

Herman objects that this language feature may get in the way of providing version safety for objects defined in other languages. MS proposal requires subclass to annotate class to indicate intention to override.

Afternoon Discussion

Microsoft's Version Safety Proposal

Given:

BC {
   foo() {}
   var x;
}
DC : BC {
    foo() {}
    var x;
}

Must distinguish between development and deployment, both cases must be supported. Client must take an active step to be version safe. Must use override keyword to be specific and use type casting to choose properties. Tuned for using COM objects without version annotations.

Relation to namespaces? A namespace is just a unique tag, to select visibility. Herman is open to this idea but objects to the "use" syntax. Here's an example of using namespaces:

package p1;
namespace N1;
namespace N2 extends N1;
class C {
   N1 b;
   N2 b;
}

Herman sees this as leading to non-linear progressions of classes, introducing too much complexity. Waldemar replies that namespaces are just names, no real savings to constrain progression of versions. Herman sees this as complicating metadata, too complex to explain to developers.

Patrick suggests calling them "FACETS" instead of namespaces, since they evoke what's visible to the beholder of an object.

Use cases: 1. developer controls visibility, 2. user selects overrides. The two main choices.

Waldemar: Here the issue is on whom we place the burden of getting versioning correct. We can place it either on the library developer (1) or on the end user/web page scripter (2). If we place it on the end user, then the library developer cannot be sure that ever versio nof that library not only used the versioning facilities but actually got it right. If some end users didn't use versioning or didn't get the code exactly right then the library developer may be unable to introduce a new version of the library without breaking existing web pages. On the other hand, if the developer controls visibility then no matter what the users do, the developer can introduce future versions that do not break existing web pages.

Herman is concerned about the details, member lookup issues, doesn't want to have magic transformations.

Chris suggest an ACTION: Write down the namespace proposal, reduced to essential form.

Patrick muses that IIDs themselves could be used as facet/version tags, which would be sufficient metadata for COM.

Interface Proposal

class C {
   a = 4;
   b;
}
class D : C implements I {
c;
   b;
   x;
   y;
}
interface I {
   x;
   y;
   a = 6;
}

Conflicts? Can behave like Java. If I has a, which is distinct from C::a, there's a problem if implementors of I are subtypes of I. We need to break the subtype relationship. A D is not an I. Instead, we can coerce a D to an I:

d = new D;
(d.a == 4)
i = (I)d;
(i.a == 6)

Herman objects, to make this work on MS implementation would need to allocate an additional object. What about equals? Object(d) == Object(i)? Can interfaces have implementations? If so, call them mixin classes instead.

Chris: abstract methods, can we have disjoint implementations with the same name?

Herman notes that :: is used in JScript to bind objects and methods in their DOM:

function window::load() {}
function window.unload() {}

Waldemar stated that he didn't think that this usage would necessarily conflict.

Waldemar notes that x@T is a "weak" typecast. Herman points out that JScript's preprocessor uses @.

Question, should E4 have interfaces at all? [I'm not sure if this was resolved.]

Herman, JScript cannot support mixins, as implements is already being used for implementing COM interfaces.

Dave argues that a "scaleable" language should have interfaces.

Waldemar argues that namespaces themselves are fundamental to JS2, a must-have feature. A decision is made to table this discussion, and define a common subset we can agree on.

Herman isn't comfortable with namespace proposal as is. The keyword "use" is the most troublesome issue. Chris asks if use could be subsumed as a feature of import. Dave says that the good thing about "use" is its selectivity. Waldemar says that override is only sufficient for client controlled versioning.

Operator Overloading

Herman talks about a common overloading scheme, used by various MS languages. It supports arithmetic overloading, C++ operators. Implemented as

static T op(T, C)

Provides conversions to/from your T, explicit conversions only with a cast. Doesn't support overloading (), [], ., ::. Uses canonical naming for universal cross language access.

Waldemar's proposal: operators selected by multiple argument dispatching. Must not allow hijacking of operators for system classes. Can static overloading get a different answer from dynamic dispatch? Waldemar says yes.

Herman argues for early binding, so inlining is possible. Waldemar says that proper interaction with class hierarchies requires virtual dispatch.

Action: Chris should send Herman a scenario for using units and arithmetic operators.

Waldemar suggests desire to overload operator new, (), and []. For example:

c = new expr(3, 4)

calls overloaded operator new() if expr evaluates to an instance of a class with an overloaded operator new.

Constructors

Constructor syntax was discussed. A constructor attribute would be used to declare constructor methods, which can have different names. Exact syntax will be provided by Waldemar.

Actions

  1. Define meaning of []. Should declared slots be enumerable?
  2. Formalize namespaces/facets.
  3. Try to come up with a better name than "namespace". View? Facet? Aspect? Interface?
  4. Waldemar needs to define const expressions.
  5. Should we generate a delta to E3 or an appendix?
  6. Come up with agreed upon subset of proposals.

ECMA TC39 Business Meeting

Future Meetings

I18N

Sam was absent, so there was no discussion of internationalization issues.

WAP

Dave discussed WAP, forum was canceled at previous meeting. WMLScript may be derived as a subset of ECMAScript 4. There's a need for a binary encoding of WMLScript for small devices. Open issues: libraries, regular expressions, I18N. Nokia may be interested in ECMA's assistance in subsetting the language. Asko Komsi at Nokia in Cambridge is a good contact.

Participants

Patrick Beard

Netscape

beard@netscape.com

Rob Ginda

Netscape

rginda@netscape.com

Waldemar Horwat

Netscape

waldemar@netscape,com

Mike McCabe

Netscape

mccabe@netscape.com

Peter Torr

Microsoft

ptorr@microsoft.com

Andrew Clinick

Microsoft

andrewc@microsoft.com

Herman Venter

Microsoft

hermanv@microsoft.com

Chris Dollin

HP

kers@hplb.hpl.hp.com

Dave Raggett

HP

dsr@w3.org

Jeff Dyer

Consultant

jeff.dyer@compilercompany.com