Areas of substantial agreement

Language Execution Model

E4 will require all names in type expressions to denote constant values.

Expandos / Dynamically Added Properties

The semantics of a[b] will be decoupled from a.b. For legacy objects, the behavior will be unchanged. How this operator will be defined for new objects is yet to be settled (operator overload, and individual member attributes are two suggestions)
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.

Decimal Arithmetic

We agree that there should be decimal and binary arithmetic. We have yet to decide how to switch, i.e. how the choice is exposed to the user. Additionally, the proposal subject to the experiments to check on compatibility issues.

Overloading

We agree to adopt the mechanisms in Netscape's liveconnect mechanism as the basis for "function agreed".

Units

Only affect to the core language is in the area of literals and overloading. The rest will be in an additional libraries.
Waldemar and Chris will work on tidying up a proposal for the next meeting

Declaration Attributes

Consensus: declarations may be preceded with an id, followed without a line break by any sequence of identifiers and constructors. Users are free to pick the initial identifier, and in many cases a scope modifier will do the job. In case the user is not enamored of any modifier, "attributes" will be recognized as a an "identity" operation which does not modify the meaning of the declaration

Superconstructor

Either you explicitly call super at the start of a constructor or an implicit call to super will be inserted for you.

Areas without substantial agreement

Deliverables and scheduling

I'm concerned about not making progress
Action: Waldemar & Herman should collaborate on an informal document not unlike the regular expression document.

Versioning, Namespaces, Interfaces

I may have this wrong, but there appears to be near general agreement that there is a need to solve the versioning problem and to support interfaces. Unfortunately, whenever we progress to the point of detailing proposals, the relationship of these two with namespaces comes up, an area without general agreement.
Action: Write down the namespace proposal, reduced to essential form.

Operator overloading

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.

"Dollin Principle"

Chris proposes an interpretation on interface types as a means for preserving the principle. Herman wants to resolve the overloading at compile-time. Waldemar thinks you may need to do so at run-time. It should be easy for programmers to write programs that can efficiently exploit static compilation.
Waldemar commits to providing a document by Easter on member lookup and classes.

Static blocks

"static {}" in the Microsoft implementation follows the Java syntax. In Waldemar's proposal, the {} does not delimit a new scope, so static is just a syntactic convenience in which the static modifier is distributed throughout the declarations.

Semicolon insertion

Disabling the automatic semicolon insertion on line break as a consequence of strict is highly controversial.

External dependencies

I18N

We lost Richard Gilliam, and I have been unable to find a replacement within IBM.

WAP / subsetting

Despite a promising beginning, there has been little follow through.

Other