We were talking about setting up 3 lists. Deferred to next meeting so that Clayton can report on progress
Rok went through the changes explaining the details. The diffs went a bit wrong ... We will discuss this further later today.
Functions.prototype.apply and .call [NB]
Norris circulated a paper copy of the proposed text and went through it. Mike asks if anyone has a problem with it becoming content agreed? Waldemar states the definition of apply doesn't allow null or undefined for thisArg. Subject to these being added, Mike resolves that this will become content agreed.
Herman asks about the benefits derived from adding these to the language. "How many people are asking for this and why?". Norris talks through the changes, for instance the new multiline flag.
There are some other Perl5 features which haven't been brought into the proposal and may be worth consideration in future. Norris proposes this goes forward as function agreed. Waldemar has a number of points to make to ensure that the functionality is fully specified. This was discussed in part at the last meeting.
Short hiatus while Herman's note on classes is photocopied. We think about starting with Chris's note on type inference vs expando, but decide to back off to a broader level to set the context.
Herman offers 3 choices a) like Java on first use, b) just say no, c) load and initialize in lexical order of declaration. The first 2 have a number of drawbacks, so Herman proposes we adopt (c).
Bill says that some folks dislike (c) when a class has an expensive static initialization. He proposes initialize on 1st reference but on the granularity of class variables not the whole class. Waldemar points out some problems with such an approach. He prefers (c). Chris also prefers (c) but is interested in how often circular dependencies arise in practice. Herman says it happens all too often. The lexical order approach is easier to understand for programmers. Chris suggests that programmers are in general not well placed to deal with the initialization order when using (b). The group seems well disposed to agreeing to (c).
Access to instance vars of outer classes. Herman proposes we don't follow Java, but stick closer to C++. Some discussion followed on the details, e.g. the effect of the static modifier on inner classes. Mike proposes we defer finalizing our choice until the rest of the modularity spec is fleshed out. Chris queries Herman's proposal to drop packages in favor of nested classes. Waldemar concurs. Once we buy into packages, we can then independently decide whether or not to allow nested classes, says Chris.
How should we distinguish instance and class variables? Herman suggests most programmers will be surprised in the default is for class variables rather than instance vars, hence suggests we use a modifier to mark class variables. The precedent is to use "static". We could agree to static var x and field var x but what should var x be? Waldemar doesn't like the idea that var x means a variable outside a class and a instance var inside a class. C++ takes this approach and annoys him.
class foo
{
/* class initialization */
static var x = 45; /* static is needed for this to work */
if (x > 30)
...
}
The value of flexible code for class initialization is that it permits you to modify the class depending on the environment. We discuss whether we could treat var x as a kind of local variable for use only in the initialization code. Herman says the desire to make code intuitive cuts both way: to avoid the need for "static" when writing class initialization, and to avoid the need for "field" when writing instance code (methods).
Herman talks about cutting and pasting code for a class into a package. Unless the default is public, visibility problems are likely to arise. Waldemar questions Herman's claim that visibility restrictions are expensive. Waldemar mentions his idea for lexical scoping as a way to avoid this.
Herman wants to avoid a performance hit which would effect nearly every access. He suggests that making the default to be "public" avoids a lot of problems. This would make it easier to write simple compilers which don't have a lot of smarts. Sophistocated programmers can and will add modifiers when they want to restrict visibility.
Waldemar says that Herman's choice would prohibit versioning. He gets up to draw an example that shows why you can do visibility with zero cost.
class foo
{
private a;
... p.a ...
}
... p.a ...
class bar extends foo
{
public a;
}
The p.a in class foo is interpreted as a mapping
scope x name x left_type --> slot
Waldemar says that the compiler can deal with scope x name at compile time to produce a qualified name. At runtime you cross this with the left_type to identify the slot. In essence this technique renames private identifies to avoid conflict with public identifies.
Rok questions whether this would work for "protected". Waldemar thinks yes. Rok is concerned about the size of the mapping tables needed. Herman says that creating the tables isn't cost free and is concerned about bloat. Waldemar says that the table approach is similar to vtables for use with methods and is used in both C++ and Java.
Herman proposes an alternative: to make public the default as this reduces the table size to just the public slots of a class instance.
This touches upon the situation where a base class is versioned separately from a derived class. It is undesirable for existing code to break when this happens. It is similarly undesirable for a derived class to hide a public variable of a base class with a variable of its own.
Waldemar writes an example where versioning matters:
old package p supporting only version 1
var q;
class C
{
public x;
method y()
{
return 7;
}
}
new package p supporting version 1 and 2
class C
{
public x;
public<2> bar;
method y()
{
this.bar++;
return 7;
}
}
.....
import p;
class D extends C
{
public bar;
}
var d = new D;
d.bar = 17;
y();
print d.bar /* changes from version 1 & 2 of package p */
Waldemar proposes that all new variables in a new version of a package are marked as belonging to that version to avoid clashes with variables in code that imports this package.
Mike summarises. Waldemar has the moral high ground of greater robustness while Herman would like to keep things simpler and place a greater burden on the sophistication of the programmer by asking her to use static typing.
Herman says Microsoft's script engine doesn't construct the tables and doesn't support qualified names. Waldemar says Netscape already uses such tables, so the additional cost would be minimal. For him there is next to no difference in cost in dealing with dynamic and static identifiers. Over lunch we discuss how important this is or whether or not the principal use cases are in fact edge cases as Herman thinks.
Mike talks about process issues for proceeding with modularity work. The fact that we have come down to 2 positions for versioning is a great advance. We need to write down the choices and the factors effecting them in a single document written with the participation of both parties. Mike proposes that Waldemar incorporates the opposing views into his documentation set. Waldemar agrees to do this with the consensus of the room.
We continue on from the mornings discussion, this time with a document showing the correct diffs.
Waldemar would like there to be a way of naming constructed functions so that for instance you can create recursive functions using the new Function statement (example from Chris). Waldemar sees the main use, however, as being for debugging.
Discussion about syntactic ambiguities. Basically you shouldn't be allowed to start a statement with "function".
Rok agrees to modify the grammar to allow an optional identifier but to avoid spelling out the semantics for the name and to leave in a note for the group to come back to before the content is finally agreed. In addition that statements can't begin with the reserved word "function".
Dario summarizes the changes. The spec was formerly underspecified. Some discussion about array prototype and instances. Array get and put are already non-standard. Microsoft proposes to change get to not to walk up the prototype chain. Mike M is unhappy. Mike C asks Dario to take ownership and to consult with Mike M. This will be placed on the agenda for the April meeting.
He intended to write something up. The issue is to do with trailing comments. This is defered until the March meeting.
Motivation written originally for Netscape, but generally matches what we discussed in previous ECMAScript meetings. He then talked about types. Dave asked what about adding "char" for Unicode characters. Waldemar thinks that is ok - using a 16 bit value as per Java.
Compound types e.g. the ability to say whether or not a type permits null or undefined. This is useful for detecting errors in calls to functions. Waldemar is now thinking of flipping the sense of his postfix modifiers, i.e. to make the default allow null and to require the ! as a postfix modifier when you want to prohibit the use of null as a value. Mike commented that it may be better to use a type operator as this would be easier to understand.
The integer type allows integers of arbitrary size. The motivation for this was unclear in discussion. Waldemar retorts it allows you to write expressions which successfully return the same type for integer values without suffering from overflow problems and issues such as whether to convert them to other types e.g. double or whether to keep to the original integer type and confuse naive users who don't understand modulo arithmetic.
Waldemar wants to move to a streaming execution model where the entire program is processed in one pass. He explains his model for deferred binding of references. Chris is concerned that Waldemar's approach may impact the ability to write smart compilers. Waldemar thinks this isn't a problem.
He wants a large subset of existing JavaScript programs to work in version 2.0. Some existing programs may need conversion but this is straightforward except for eval.
Some concern about future extensibility impact of the optional argument syntax. For instance the use of the term "traditional" preceding "function". Dave wonders about having the return type immediately following the argument list without a preceding word ("returns" or ":"). If we go for id:type rather than type id, then the use of ":" would be consistent. Herman prefers the ":" syntax for type annotations.
Currently lacks support for interfaces. This could be added later.
A more controlled means to extend classes than expando. It is a kind of anonymous subclass, but cannot add new instance variables. Herman likes it! Mike notes that he feels that the examples shouldn't need the public modifier.
Group feels that it should be an error not a warning. Perhaps we should differentiate developer errors from user errors?
if we only allow "import <ImportList>;" we would then need use a try-catch wrapper, e.g.
try {
import foo;
}
catch {
...
}
Dave requested a means to deal with language supersetting (e.g. adding style rules) or language subsetting (e.g. for mobile applications where the full language is too costly to support). Waldemar suggests we allow this to be specified on a block level rather than being limited to the complete file.
Waldemar introduced this as a language extension rather than as part of core. This is principally to support units. Some discussion about need for an abuttal operator for combining number and a following identifier e.g. 10em.
Waldemar's grammar makes it impractical to allow semicolon insertion except at well defined points such as before "}", "else" etc.
At a bare minimum you should be able to write code that works in ECMAScript 1.0 and 2.0. Full backwards compatibilty would be rather painful. A modal implementation gets around this - you switch the compilers behavior according to the language version rather than try to create a single language with broad compatibility which would be a support nightmare.
The discussion will be continued in the March meeting. Clayton should be asked to take this on for the business meeting.
Location: Netscape, Mountain View.
Starting time: 11:00 for 1st day and 9am for the 2nd.
Clayton will own the agenda for the 1st part of the meeting which concerns business planning for ECMAScript. We will then switch to the technical discussions. The following meeting is Thursday April 29th (one day).
Action: Dave to organize a subagenda for the time spent on modularity in the March meeting.
Can people send mail to Waldemar as input to the revised document on modularity which will contain an indication of the contentious areas and the various proposals on the table. To join the modularity email list, please email Chris Dollin <kers@hplb.hpl.hp.com>. We will try to set up a meeting of the modularity subgroup before the end of March.
At the end of the meeting, Dave and Andrew proposed that the subgroup meet at Microsoft in Redmond, on Friday 26th March, start time 10am. The meeting will be hosted by Andrew Clinick.
Chris talked through his note. His goal is to find a way to support expando in a way that is clean and consistent with classes etc. Failing that to get rid of them from ECMAScript 2.
Herman has reservations about both the premises and the conclusions! He is happier to adopt Waldemar's class extension mechanism and to drop expando. He would like a general hash table mechanism not just the string keys in ECMAScript 1. Waldemar has made some steps in this direction in his proposal by allowing you to overload the square bracket syntax.
Herman comments that by introducing a new syntax for expando, Chris is in effect blocking old style programs from working. Authors would be forced to learn the new syntax and wouldn't be able to get their code to work simply.
The simplicity of HTML onclick attributes makes them appealing, but don't allow you to use a package keyword. Netscape relies on the version of the first script element to set the version for such attributes. In the absence of a script element, the script engine would have to assume the default version.
Waldemar has a 3rd solution that preserves the dot notation and relies on the versioning mechanism. statically declared properties have a greater priority than expando properties with the same name. Herman questions how this interacts with subclassing.