Notes from August 22, 2000 meeting between Waldemar Horwat and Herman Venter

General: Herman is readying an implementation of JScript for servers and wants to freeze the language and make it easily interoperable with Microsoft's .NET runtime. Waldemar is concerned about the language's applicability to browsers and retaining the language's dynamism, which he sees as the language's differentiator. He's concerned about the language's drift towards Java or C# because he thinks that there is little need for another language in that space, and the result would be inferior to C# for static programming anyway. Herman also recommends that new server projects use C# instead of JScript, seeing the new JScript as a language geared towards developers already used to programming in JScript.

• Strict mode: Herman would like to eliminate it from Edition 4 and leave it as extensions for Netscape and Microsoft to implement. Waldemar is willing to agree but is worried about divergence between Netscape's and Microsoft's strict modes (Microsoft's called Option Fast). Herman says that Microsoft's Option Fast serves a different purpose from Netscape's strict mode. Waldemar would like input from the rest of the group.
• Herman would prefer to eliminate the 3_in syntax for units, leaving only 3in and 3 "in". Waldemar is OK with that, subject to agreement from the rest of the group.
• Herman expressed some willingness to accept the :: notation for namespace qualification and doesn't think that it would fatally clash with Microsoft's current usage of ::. The plain . doesn't work for a member qualifier -- a.b.c is interpreted as (a.b).c rather than a.(b.c). Waldemar dropped the semantics of supplying multiple namespaces to a single member lookup: a::b::c used to mean "look up the c that is in both namespaces a and b"; now x.a::b::c means x.(a.b)::c -- a.b should evaluate to a namespace in which the name c is looked up. Herman suggested the syntax x::a.b.c instead of x.a::b::c, but Waldemar doesn't like it because it goes counter to C++ expectations and associates in the wrong way: one would have to write (x::a.b.c).d instead of x.a::b::c.d.
• Waldemar clarified that, when a is not preceded by a dot, either a::b or a.b can be used to look up member b of namespace a.
• By Herman's request, Waldemar took the @ operator out of the Edition 4 proposal. It will be a Netscape extension.
• Waldemar suggested that there be some way to make compile-time array constants (something like [3,4] doesn't work because it creates a mutable array) and/or read-only arrays, but no consensus was reached.
• Waldemar added attributes that take arguments to his proposal and figured out a way of doing it while keeping the grammar LR(1).
• Herman does not want scope blocks (i.e. scope{ ... } creating a local scope) in Edition 4. Waldemar is unhappy about that because the working group spent several days on this subject and earlier appeared to reach consensus to keep them but would go along if the rest of the group wants to drop them, in which case they would become a Netscape extension.
• Herman does not want attribute blocks (i.e. private{ ... } distributing the private attribute among the declarations in ...) in Edition 4. Waldemar is also unhappy about that but would go along if the rest of the group wants to drop them, in which case they would become a Netscape extension.
• Microsoft currently accepts catch (x:RangeError) but not var x:RangeError. Waldemar doesn't think that this is a significant issue if RangeError is a host object.
• Waldemar expects to be able to write var x:foo if foo is an Edition 3-style constructor of prototype-based classes; this would mean that x can hold any object that has foo.prototype on the prototype chain. Herman has some reservations.
• Herman doesn't like the volatile attribute and would like to rename it to virtual. Waldemar agrees. There already is a virtual attribute and the issue of what the new virtual would mean was not discussed; there probably is disagreement there regarding whether the overriding method must match the base method's signature or not.
• In addition to the override attribute, Microsoft has a hide attribute that creates a new vtable entry rather than reusing an existing vtable entry. Operationally, hide and override appear to be equivalent for code that dispatches on untyped variables, but their behavior differs when dispatching on variables with static types. Waldemar says that hide breaks the Dollin principle. Agreed that hide will be a Microsoft extension rather than a feature of Edition 4.
• Herman asked about mayOverride. Waldemar explained that they are useful for writing scripts that define a method that is present in the base class on some implementations/platforms but not on others.
• Herman doesn't want to have anti-attributes (attributes such as implicit, instance, concrete, etc. that negate other attributes), saying that they are unnecessary. Waldemar wants to keep them to turn off attributes that were earlier turned on by user-defined attributes. No agreement.
• Herman asked about the explicit attribute. Waldemar explained that it's necessary for versioning to declare a new version name itself in a way so that it cannot clash with a name defined in another package, solving a problem discovered by Dave Raggett in an earlier meeting. Agreed to keep it.
• Herman doesn't want user-defined attributes to be combinations of existing attributes (i.e. defining const spriv1 = static private Version1 and then using spriv1 as an attribute). Waldemar thinks that they are an important abstraction mechanism, enabling one to switch attributes on a large number of definitions by editing one line of code. No agreement.
• Microsoft has an expando attribute that one can put on a class to allow instances to hold ad-hoc properties. In light of the previous agreement to restrict ad-hoc properties to only classes that are marked as allowing them, this is clearly needed. Waldemar will add it (perhaps proposing a different name) to Netscape's proposal.
• Microsoft has a protected attribute, where protected means accessible only in subclasses (like in C++ but not like in Java, where the local package can also access the definition). Waldemar doesn't care whether this is in the language or not.
• Herman doesn't want to have the local, scope, and global attributes. This topic needs further discussion, especially since there was consensus in an earlier meeting (October 1999) to have at least some of them.
• Herman doesn't want the language to have the "early Pascal" behavior where in the program

  const x = 10;
  {
     a = x;
     ...
     if (foo)
        const x:t = 20;
  }

  variable a gets the value 10. Waldemar says that this behavior, or something similar, is essential to support Netscape's dynamic superset of Edition 4. There was a little progress, but no definite agreement was reached.
• Microsoft uses static { ... } as a static initializer inside a class and does not allow anything other than definitions inside a class. Netscape treats it static { ... } as distributing the static attribute among the definitions inside the block. Netscape allows ordinary code inside a class; that code is executed at the time the class is defined; local variables can be created using the local attribute. No agreement.
• Herman says that classes should be initialized lazily on first use. Waldemar says that classes should be initialized as part of their package loading process. No agreement.
• Herman would prefer to not have anything other than class definitions inside a package but was willing to allow other things (that would be internally collected into a special class). Waldemar wants to allow arbitrary code inside a package.
• Herman has some reservations about export. Waldemar wants the facility in some form, although is willing to change the syntax.
• Herman would like to issue a warning about declarations that mix typed and untyped variables such as var x,y:Integer, where x's type is actually Object. This is a consequence of us adopting the Pascal-style syntax rather than the C-style var Integer x,y. Waldemar agrees.
• Herman suggested syntax distinguishing constant definitions from compile-time constant definitions. Waldemar pointed out that this was what compile blocks (which were dropped at a previous meeting) had been designed to accomplish.
• Waldemar clarified that any has been replaced by Object; he hadn't gone through the entire web site with the search-and-replace yet.
• Herman presented a way of interpreting literal numbers as either IEEE doubles or 64-bit integers without loss of precision and without using source code tags. Waldemar is curious but needs more details to understand the proposal and its implications.
• Herman would prefer that every constant declaration also include a definition: const  x:t=expr. Waldemar currently allows a constant to be declared before it is defined: const x:t; ... const x=expr. Waldemar will look into why he had thought that this was necessary and agreed to drop it from Edition 4 if it turns out to be unnecessary.
• Waldemar's proposal has named class constructors that are callable as though they were static methods of a class. Herman said that it would be difficult to implement two different class constructors with the same signature but later found a way to do this.
• There was some disagreement about the constructor syntax. Herman wants to use the Java-style syntax of declaring a function with the same name as a class. Waldemar wants to use the constructor keyword instead of the function keyword. Waldemar agreed to make constructor into an attribute so that one would declare a constructor using constructor function f(...) {...} instead of just constructor f(...){...}. The constructor attribute would be optional if f was the name of the class. However, Waldemar thinks that giving special meaning to a method that has the same name as the class is confusing.
• Herman doesn't want the rest parameter to be able to take named arguments because of efficiency reasons. After some discussion it turned out that the inefficiency can be avoided for the cases where the rest parameter is defined as a typed array because typed arrays don't accept named arguments. If the rest parameter has no type or is a plain array then the code appears to be no less efficient than a plain dynamic dispatch where the signature of the method is not known at all. Herman reluctantly agreed to allow the rest parameter to accept named arguments but only if there are no parameters other than the rest parameter. Waldemar insists on no such restriction. No agreement yet.
• Discussed whether static class members should be visible via instances. Microsoft is evenly split into two camps on this issue. Waldemar says that static members should be separate from instance members to match Edition 3's behavior: In edition 3, a static member of a prototype-based "class" c is a member of the object c and is not present on the prototype chain of c's instances. Members of c.prototype are not static members of c for a couple of reasons: they can't be accessed via the syntax c.foo(), and writing to one through an instance creates a copy inside that instance rather than modifying it in place.
• Herman would like to use the super.foo() syntax to call a method of a superclass. Waldemar prefers the this.super::foo() syntax but agreed to also support Microsoft's syntax.
• Agreed that for security reasons there should be no way to access a method of a specific ancestor class other than via super.
• There was a long discussion about packages and their names. Herman wants the names integrated into the .NET namespace, so that a package is defined using a dot-separated name and imported using a dot-separated name, with the system taking care of figuring out where the package lives and how to load it. Waldemar points out that dot-separated names are meaningless in a client environment, where a script that imports a package located somewhere on the web would most likely identify that package using some URI. Waldemar also has parsing difficulties with the language grammar if dot-separated names are allowed for package names. Tentatively agreed on a compromise where a package is defined using a dot-separated name and can be imported using either a dot-separated name or a string. The interpretation of the string would be host-defined (on a host such as a browser the string could hold a URI).
• In Microsoft's current implementation, executing import foo.bar.baz causes a global variable foo to be defined. This can be a problem if foo is already used for something else. Agreed that this will behavior will not be in Edition 4; to access a package via a name, the import statement will explicitly have to introduce an alias name for the package: import f=foo.bar.baz.
• Herman doesn't like the use import syntax and says that opening the package's namespace should be the default. Waldemar agreed to rename use import (the kind that makes a package's globals available without qualification) to import and import (the kind that makes requires qualification) to qualified import.
• Herman and Waldemar agreed to late-bound dispatch for operator overloads. Waldemar will take a look again at the C# syntax for declaring operator overloads and will come up with suggestions for Edition 4. (The current syntax in Netscape's proposal is out of date.)
• Did not discuss ways to use reserved words as identifiers.
• Did not discuss typed arrays. This looks like it may be a contentious issue.
• Discussed class extensions (declaring methods of existing classes such as String), but not in detail. Waldemar says that users have been demanding this functionality.
• Herman would like more motivation for the use statement that selects the version and options (strict, etc.) of the language.

Notes and mistakes written by Waldemar Horwat