scribe: Dave Raggett <dsr@w3.org>
Some missing from a few meetings back (AC) does anyone care? General feeling is that we should continue to take notes.
A fairly boring event. Reports on what the various committees have been doing for the last six months (for about 6 hours). 3 companies withdrew including Apple and BT. Oki Europe, Dell and Dialogic joined. 3 members are being expelled. Happy with TC39 except for WAP scripting stuff.
We should invite them [WAP people] to come and talk to us.
IBM is upset that WMLScript claims to be a subset of ECMAScript and would like them to remove the reference or at least just say "inspired by".
Should we invite them to formally define a subset of ECMAScript under the aegis of ECMA? WMLScript seems to be a very weak subset, is there scope for a larger subset? Its probably a good idea to expose the WAP Forum membership to our views.
Action: CL to contact Peter King of Unwired Planet.
ETSI Intelligent Network Group would like to talk with us. (Telecoms stuff)
ECMA TC32 - doing Internet Screen Phones (interesting) the idea for showing Web content in small screen on telephones. (Get URL from ECMA site.)
ECMA 5.0 CD's are now available.
Laurie looks after all their website and is overworked. If we want something done, we should perhaps consider running it elsewhere.
The admin list is formal admin. We have two others. One for I18N and the ECMAScript WG list. HP Labs also hosts a technical list.
Action: CL to host 2 technical lists (I18N and general ECMA TC39 WG) moved from ECMA server.
Action: CL to spruce up the lists to remove people who shouldn't be there and to ensure that every one who needs to is on the lists.
AC has had repeated problems in getting new people to the main mailing list.
Everything has been merged in as of last Friday. In pretty good shape, but please look through to make sure your changes are in correctly and let Bill and Mike know as soon as possible.
The document is on the ftp repository, linked from the bottom of the TC39 document's table (Mike's site).
ftp://ftp.gibbons.org/private/ECMA/
Some question about the use of change bars and underlining.
All comments should be sent directly to Bill.
Mike talked about the status document, and we won't be adding new items unless the whole committee agrees. Bill will have to assign new section numbers for the items covered by the status document. Bill has done some of this already, e.g. for substring.
The proposals document hasn't been updated at this time. Lacking nested functions proposal and update on regular expressions.
Do we prefer small documents for review or a larger merged document? Waldemar said that delta's are appropriate for changes to existing stuff and separate docs for new stuff.
we discussed this earlier (GA report).
CL will arrange to invite a WAP representative to a future meeting of ECMA TC39 ECMAScript WG (probably in March).
Feb 19th (one day), then March 29/30 (two day hosted by Netscape). The one after is most likely to be 2nd half of the week of April 26th. Tentatively suggest Thursday 29th April.
Andrew, Rok, Herman and Dario arrive ... (Fog and endless circling around San Francisco)
Zibibbo in Palo Alto for 6:30.
Richard started with a summary. Effort started last September with Tom McFarland of HP, noticing some problems. Commissioned a subgroup which had a meeting in November the day before the main ECMAScript committee meeting.
A lot of questions about just how much should be in ECMAScript standard, and concerns about bloating the standard and the size of the run-time, e.g. large I18N tables.
Richard drafted a proposal which in discussion evolved into a two tier proposal with an I18N library which we hope would be available on most but not all systems. We talked about what should be in the core language:
1998.11.18 meeting notes on Mike's site
ToLocaleString for most cases is simply defined in terms of ToString. It takes a locale, but the type of this parameter isn't defined in the core language (it's an object defined in the library).
Problems with parsing are much trickier than formatting and hence should be in the library. Character Case mapping will take a locale parameter StringtoUpperCase() etc. Turkish is the tricky one. Another one is German sharp S which adds/removes a char.
Unicode normalization is another fun one. There may be several different legal ways to represent text with accents, e.g. umlauts. Propose Unicode normal form "C" (UTF16) as its the 'smallest'. The idea is that strings are normalized by the input mechanisms so that programs will only see normalized text strings.
Unicode version: we should update the ECMAScript standard to refer to Unicode 2.1 or later (to include the Euro sign).
Regular expression support for Unicode strings is not intended for natural language matches. We want digits to match all digit characters not just 0-9.
Some discussion about the size of the tables needed to ensure platform independence. Considered too big to require. The plan is to decouple the description of the I18N library from the ECMAScript standard by placing it in a non-normative annex or an ECMA technical report.
Hopefully, the situations where you have to go in and parse the text will be fairly rare. Most of the ECMA functions operate on code points (in UTF16 characters > 0xFFFF take two code points, but these are very uncommon), but the I18N library can be used when needed to deal with natural language text.
Richard then took us through the details of his document.
Suggestion to add URLs to the Unicode report to help people reading the proposal. Unicode 3.0 should be done by September. Referring to "Unicode 2.1 and later" avoids a strong dependency on the 3.0 release schedule.
Programs may construct strings that are not normalized. However strings derived from external sources should be normalized by the time the program gets access to them. If the strings are not normalized then the I18N library functions may not operate correctly - the biggy is string comparison. Normalized strings can be compared on a bitwise basis without the need to parse the strings as Unicode characters.
String concatenation isn't guaranteed to return a normalized string when supplied with normalized strings, although this is unlikely (the second string would have to start with a combining character). It would be cheap to fix this.
There should be a recommendation that external libraries return normalized strings.
Transcoding from other character encodings (say Big5) makes it pretty easy to normalize strings.
What about escaped characters? General feeling is that is tough.
Programmers can call the normalize function in the I18N library - but the tables for this are pretty big. say around perhaps 20K to 30K. Java already has this in its libraries, although this is not yet exposed in the Java API. It would be an error for string contenation to guarantee to return normalized strings. Programmers can always call the normalize function if required.
Bill suggests we adopt a rule that there is no decomposition. We also say that the language isn't guaranteed to work if strings are not imported in normalized form. Within the core of ECMAScript, all operations are on code points.
ToNumber - the extension to treat all Unicode decimal digits (e.g. the arabic ones) as digits and all Unicode whitespace characters as whitespace. We could perhaps ditch the decimal thing?
Some questions about minus signs (is ASCII '-' a minus etc.) and 'e' in numbers, e.g. what about wide 'e's? Herman proposes that the status quo should prevail. The whitespace stuff is fine, though.
Waldemar pulls out an O'Reilly book on regular expressions to show how character classes can be expressed, e.g. [[:alnum:]] matches a generic Unicode alphanumeric character class rather than say the ASCII definition [a-zA-Z].
Action: I18N Subgroup needs to work on I18N regex stuff again and come back with this to the next meeting.
Some discussion about toLocaleString when locale is null or undefined. Feeling that the default locale should be used in such situations.
We then turned to the issue of how to progress to Content Agreed.
Action: I18N subgroup to work with Bill on drafting text as though it were in the full spec. This will be reviewed by the whole group at the March meeting.
It would be nice to have the non-normative technical report to be ready by Summer, if we are lucky by March. Question: do ECMA technical reports need to be balloted? ISO does accept technical reports.
Action: I18N subgroup to provide some idea of the size of the TR in the March meeting. The priority is the core stuff that goes into the normative text for ECMAScript v2.
Dave asks Herman to give his perception on progress.
Attended teleconference. The idea of using Java as a starting point, and to worry about concerns about dynamic properties and classes. Some email mainly involving Chris.
Chris would like to scope names via packages rather than classes and has been vigorously advocating that.
Chris says - putting namespace control into packages and not in classes would be a good idea, but he is prepared to compromise on using classes for namespace control.
Chris gets up and talks about static binding for x.f. Today, ECMAScript doesn't scope what f can bind to. Two schools of thought - one is that f is an identifier that is statically scoped, the other school is that it is dynamically bound.
class X
{
private var s
function f(z)
{
z.s; // does s statically refer to private var s ??
}
}
The dynamic view is that s refers to the private var s only if it is dynamically found to be an instance of class X. The static view is that s is statically bound to the private var s via scope rules. Note that this wouldn't hold if var s was declared as public.
We back off to cover the ground at a higher level.
Herman says we haven't made a greal deal of progress. We hope to use this meeting to make progress on core issues as that will then allow us to sort out the other dependent issues.
Waldemar: we are talking about programming in the large and how experienced/disciplined scripters can write robust code.
Richard asks so we are talking about large programs?
Herman and Waldemar explain the need for scripting with large libraries. Our target audience is the more experienced programmer who appreciate the need for robustness and efficiency. Bill adds that programmers of existing content want to be able to use this without it breaking.
Herman - we may be able to move away from some of the 'mistakes' in the current language, which preclude robust/scaleable scripting. This touches on the use of dynamic properties. Do these need to be folded into the class mechanism or limited to objects?
Chris asks whether the adoption of a new robust object model will effect things like regular expressions. However, the fact that regex at least has already been deployed means that we have a limited freedom to change things.
Clayton: its key to allow naive scripters to continue to script stuff very simply. The ability to allow professional scripters to develop robust code with large libraries is also very valuable.
Should "expando" [dynamic addition of properties] be supported on objects? This helps beginners but also leads to major problems for larger programs. Some discussion as to whether you can mark classes as not supporting expando.
Rok points out that inexperienced programmers will expect to be able to add properties dynamically to classes declared with the new class syntax.
Herman argues that using the same syntax for dynamic properties as for static properties precludes some forms of error detection. For instance spelling errors for property names can't be detected. This is an issue of robustness.
ECMAScript programmers already have to deal with the issue that some objects can't be expanded (ones implemented by the system).
We spin for a while ... but there seems to be agreement that an explicit syntax for distinguishing static declared objects is needed.
Waldemar proposes that only the current function mechanism for creating objects, creates expando objects. If programmers recast their old libraries built using prototype chains into the new class syntax. Then will users have to change their code too?
Our discussion seems to pivot on what the default is? Whether expando is default or not for the new class declarations.
We agree with Rok, that users of libraries should be able to ask the system to report errors rather than simply treating them as new expando properties.
We have an agreement that we need to be able to switch expando on and off. We don't have to agree the default now. Another issue is whether users can have control of this switch as well as library implementors.
x["f"] makes it hard to control the binding of f in the presence of packages compared to x.f. Waldemar gave a good argument, but I failed to capture it.
Action: Spice subgroup to figure out the interaction between expando and namespace control with packages.
var x:String;
x.blah; // throws an error since you can't add a dynamic
// property to a String
Mike calls a process check.
Lets go through what we agree on.
Action: Dave to draft a report similar to the I18N report for the next meeting, in collaboration with Waldemar, Herman and Chris.
Do we standardize this before implementation? Answer: NO. We definitely need a solid spec. before we implement but it needn't be an ECMA ratified one. There are ways of getting it out, but it doesn't have to be a public beta release. A controlled beta could work?
Can we defer any of the above features, to allow us to reduce the risk of achieving our milestones?
The new object model needs to provide a description that explains the behavior of existing objects. It is pretty much the case that prototypes correspond to classes - the standard doesn't allow you to change the prototype. The attributes associated with properties allows you to define them as read-only etc.
Instance variables may contain references to functions. This seems like a subtle difference to explain vis a vis methods.
Getters and Setters should be transparent to the users of an object.
We then tried to pick the show stoppers in the issues list:
We must be able to conform to the current set of scoping rules, i.e. run-time rules. Chris thinks of scoping as a compile-time thing and will try to wrap his head around the terminology.
Chris writes up an example:
class X
{
var slip = 42;
function foo (y)
{
return this.slip + y.slip;
}
}
class Y extends X
{
var slip = 97;
...
}
class A
{
var slip = 99;
...
}
var test = new X ; // or a subclass of X
// what do we get when we use new X, new A or new Y ??
print(test.foo(new X));
print(test.foo(new A));
print(test.foo(new Y));
In class X the meaning of this.slip is clear enough (i.e. 42) for an object created with class X. But what about objects that are instances of subclasses of X, such as instances of class Y which also define fields with the same name. Does this.slip in function foo bind to the field slip in class X or the field slip in class Y? Should we make it illegal to define public fields in subclasses with the same names as public fields in superclasses?
The scribe thought it worth typing up the corresponding example for methods:
Class X
{
function foo()
{
bar();
}
function bar()
{
print(42);
}
}
class Y extends X
{
function bar()
{
print(97);
}
function test()
{
foo(); // what does this print: 42 or 97 ??
}
}
If methods are virtual as in Java then calling test() will print out 97 since the call to bar() from foo() will invoke the method bar() in the class Y and not class X.
The preceding example raises the question whether fields are virtual in the same way as methods? If the syntax this.slip invokes the corresponding getter or setter methods, then it might be expected that field access should work in the same way as methods. That is if methods are virtual then so are fields.
But does this make sense? Is it what most programmers would expect? Does it risk brittleness as code is changed over time? Perhaps its better to make it illegal to define public fields with the same name as public fields in superclasses. How would the argument be effected if the field slip in class X is declared as private?
Herman would prefer the interpretation to match Java. That is the binding is determined at compile time, ie. this is of type X. Richard suggests the binding is dynamic and depends on who called foo. Chris suggests a compromise. Waldemar suggests Java's model relies on implicit versioning.
We then turned to what y.slip means in foo, but ran out of time.
Building upon Chris's example from Monday:
var a:X = new Y; var b:Y = new Y; a.foo( ); // what does this do? does it differ from b.foo( )
Waldemar questions Herman on whether the "Java interpretation" is relevant, as the above can't be expressed legally in Java.
Waldemar changes the example to:
Class X
{
public var slip = 42;
function foo (y:any)
{
var v = this;
return this.slip + y.slip + v.slip;
}
}
With Herman's interpretation, Waldemar and Chris argue that it makes it hard to introduce new variables.
Herman suggests that if a variable is declared as 'any' you get dynamic binding, otherwise you get static binding using the same mechanisms as in a statically typed language.
One idea would be that y can't have a field slip since the type any isn't declared as having this field. Waldemar and Herman agree that this would be too far apart from the expectations people currently have for ECMAScript.
Chris argues that the behavior of the program shouldn't alter if you add the type declaration when you know what the type is. Herman doesn't see a problem with the behavior altering. Chris says this would discourage people from declaring types. Most of us agree that adding the type when you know what it is shouldn't change the behavior.
Herman says this is all a consequence of expando. Most of us disagree. Rok says the problem arises from having several things with the same name. If the class definitions didn't have ambigous field names, then the problem disappears.
Richard says there is a choice of declaring that a given variable must of this type, or declaring that it must of this type or a subtype of this type. The former definition makes the problem go away.
Chris changes the example to:
Class X
{
public var slip = 42;
function foo (q:any)
{
var v = this;
return this.slip + q.slip + v.slip;
}
}
Herman argues for a definition of expando that means you always take a dynamic lookup hit. Waldemar suggests that we wouldn't want to do this. The type declaration of fields declared statically should be fixed and not changeable via expando.
The ability to declare that a given class doesn't support expando can be used to detect typing errors, and to improve efficiency.
Bill suggests we write down a list of attributes we would like:
Whether you can replace a value with something that has a new type or not?
Mike steps in.
We seem to agree that v.slip should mean the same as this.slip. For the time being lets assume that we will use dynamic lookup. Bill proposes that while we will use dynamic lookup, if the programmer supplies enough type information it should be possible to use a simple slot access. General feeling that this might be a stretch.
Clayton says that type info may be being used to catch programming errors, rather than for efficiency.
Chris adds to the issues list a new item:
property names versus property strings?
Waldemar writes an example:
// always returns a window of class X
function OpenWindow( ... )
{
}
OpenWindow( ... ).slip; // access slip on an instance of class X
It would be strange indeed if adding the return type to the function were to change things
function OpenWindow( ... ) : X
Herman continues to disagree, and feels its fine for the behavior to change since in his view the programmer has changed the type from the default 'any' to Class X. Herman doesn't see any as the root of the type hierarchy. You can assign anything to a variable of type any, but other types are not subtypes of any.
Herman wants to do this to allow expando while preserving a static view point.
Clayton asserts that henceforth we use 'any' to refer to the root type and that we use 'unknown' for Herman's definition.
Richard: if we want to be consistent with the existing behavior of ECMAScript, to allow things to look dynamic, but to include ways to tie things down when the programmer knows enough to make such assertions.
Rok asks can we decide on whether we want to allow or not for a child class to declare a public field with the same name as a public field of a superclass?
class alpha
{
private fred;
method F(theta)
{
theta.fred; // lookup depends on context
} // not just on type of theta
}
class beta extends alpha
{
private fred;
}
Richard wonders if we are running into problems because we are using classes for namespace management. Waldemar summarises how this is done in Spice. Waldemar says its internally consistent, its consequences are a bit surprising to most programmers.
Chris says that if you have a private field in a class, you should be able to rename it without problems. Waldemar says sure provided you avoid name clashes. This is trivial if you only use private fields for variables typed to the current class.
Mike says we are mostly accepting that dynamic lookup applies, and that adding true type annotations doesn't alter behavior. Making something private that was previously public and not accessed else where should likewise cause no change in behavior.
(Assert means throw an error if the declaration doesn't hold).
Waldemar asks what is the meaning of the following:
1. (integer)V
(X)v // where X is a previously defined class
2. var w:integer;
w = 17;
w = "17";
w = true;
w = 17.0; // is this found to be integral at run-time?
3. function f(a:integer)
f(17);
f("17");
f(true);
f(new X()); // for a cast use x.toInteger()
Does the choice influence method and function overloading?
Herman points out and we agree that casting is problematic in the current definition of ECMAScript. Waldemar retorts, yes but what do we do about it?
Chris asserts that for dynamic dispatch to be plausibly efficient, automatic casting is not a good plan. General nodding that automatic casting is not preferable. Then Mike points out the NetRexx is a counter example, but it is statically typed like Java.
Waldemar adds to the issues list:
what are the types of literals?
We talk about whether we want to introduce a distinction between integers and floats, or at least between integer values and non-integer values.
Mike says the philosophy of ECMAScript is that automatic conversion is the default, unless you state you don't want the cast. How is this done? On a per class or per package basis?
Richard points out that assert rather than casting simplifies method overloading. Mike says this is a solved problem. You make an estimate of the "cost" of each conversion for each argument and if you get a tie you have an error. If you find one of cost zero you stop and use that one.
Chris argues whether we should keep with the current ECMAScript casts or take this an opportunity to clean the definitions up. Mike argues the casts were chosen to make scripting easier. Herman says that the current coercions in ECMAScript are rather complex.
Clayton: are we agreed that the coercions are on statically declared types and can't be dynamically extensible? Chris argues that this shouldn't be ruled out.
Dealing with all possible coercions at run-time might be expensive for objects with subclasses.
Clayton proposes that we retain argument type coercion for functions with untyped arguments, and use the assert model for functions with typed arguments.
Herman argues that the current conversions are counter intuitive in some cases. Andrew suggests the assert model is easier to learn. Mike retorts that this argument would act in favor of switching to Java.
Clayton writes an example:
function f(string a, int b)
function f(int x, string y)
f("17", "13");
Chris says that Spice has a rule that makes it an error to write ambiguous overloaded declarations. NetRexx also detects the error at compiletime as an ambiguous function reference.
Waldemar makes a case for dynamic overloading.
Mike makes a proposal that we use a notion of cost to determine when to throw an error. The threshold could be set at compile time or at run-time etc, globally or on a per class/package basis
Chris asks a question:
class X class Y extends X (X)(new Y()); // is this the same as an X? y = new Y(); (Y)(X)(y); // is this the same as a Y?
Chris suggests this creates a new object.
Mike suggests we follow the Java model, i.e. casting up and down the hierarchy doesn't create a new object. Richard says we shouldn't have a special casting syntax.
Mike summarises that if we are going to support a casting mechanism then we should avoid creating new objects where practical.
Rok asks a question about casting and interfaces. If you cast to an interface
class X implements A, B r = new X; f((A)r); // what happens? ((A)r).foo
Mike asserts the result of (A)r is of type A, but the cast is of zero cost since A is a subtype of X. Some debate ensued as to whether subclasses are subtypes.
Waldemar uses a example where a web page has a script that uses a package that lives in the browser, for example the I18N library. Sometime later the browser company wants to add a new function to the package which breaks the web page.
This assumes the web page calls a method m. The library has a method m that calls p. If the new version of the library includes a new definition of p, then the web page won't work as before.
Java avoids this problem via the way functions in class files are bound using information available to it when the code is compiled. COM also avoids this problem. In ECMAScript the problem is that the code is always compiled just before its run. How can we fix this to make it safe to make additions to released libraries?
Waldemar proposes a version mechanism that marks each method with version numbers. Provided the scripter of the web page indicates which version number of the package she is using in the import statement, then the library will find the version of method p assumed by the web page scripter.
The version number acts like the interface identifier in COM. It can be used to lexically scope name lookup. This is the same kind of scoping as used for private/public fields. The new definition of method p is invisible to the Web page.
If the package is imported without a version number and the Web page attempts to call p, this results in an error. Waldemar suggests it may be feasible to use a qualifier syntax for function calls to identify which version of a function you mean to call.
Herman likes the idea. But we must be careful to avoid making the cost increase.
You could include the version annotation in the library in an interface so that new versions can exploit old functions etc. You could also include it on methods themselves.
We need to come up with a decision.
Herman asserts that to him a package is a collection of classes and functions. Packages don't export global variables. He would prefer to move globals within classes as static variables. Richard argues that its too late to do this for ECMAScript.
Waldemar writes an example:
package P
{
var global; // legal?
class C
{
static var s; // legal?
}
}
// main program
import P;
var h; // legal?
var global; // collision?
Waldemar asks if the default global namespace is the same as window reflection?
Chris says why should we stop allowing package level globals now? What about static code in packages or classes?
Its tricky to figure out what order to run the static code. Furthermore, you typically only want to run the code once.
Classes refer to each other so figuring out what class static code to execute first is hard. Cycles can also occur between packages. One idea is to treat packages as equivalent to classes for package static code. The cost of dealing with initialization is justified by the frequent occurrence and desirability of cycles.
Another idea is to limit initializers to be context free so that they can be evaluated at compile time.
Waldemar proposes a means for the library to automatically initialize itself (e.g. setting a hidden package global flag to prevent it initializing itself twice)
Afternoon Session
Same as nested functions document.
The proposal aims to resolve differences between Microsoft and Netscape implementations. Rok talked through the changes from the previous text. The scribe was unable to capture the details of the discussion.
Bill proposed that we deprecate a dependency on the current order in favor of proper lexical scoping.
Rok's examples:
with ( )
{
function foo ( ) { } // regular function
x = function foo { } // named function
x = function ( ) { } // anonymous function
}
Rok proposed that only anonymous functions would be allowed in a with statement, i.e. the first two examples would be illegal. Function declarations only happen at the top level.
Chris points out that you can't write recursive functions.
Mike sums up: we appear to have function agreed, but we need another iteration.
Waldemar suggests we keep to the current text regarding the the specification and the use of 08 and 09. General agreement.
Herman emailed a document. It only tries to capture the existing behavior (i.e. Perl4 not Perl5). Its unclear if the syntax doesn't accept the string, what should happen. Herman says he was unable to come up with language that covers all the edge cases. Waldemar suggested that we could make those cases illegal as far as the ECMAScript specification.
There are implementation differences currently for 'split'. Herman questions whether the Perl behavior is appropriate. What features should we adopt from Perl5.
Waldemar said that the syntax for regular expressions is far from ideal. Do we try to match Perl feature for feature. The O'Reilly book on mastering regular expressions has all kinds of examples. Rok wondered about how easy it would be for someone to pick this up and apply to ECMAScript?
Waldemar would like to diverge from Perl in the definition of illegal backslashes so that we could add things in the future. Herman would like to see non-normative notes covering the full details of current implementation behavior.
Waldemar asks what is the interpretation of [---X] ?
[ - - - X] [ --- X ] [- -- X]
What about [a-] and [a-\d] where there are empty strings?
What about /= is this the start of a regular expression?
How do parentheses work? We don't explain this but we should. There are a variety of questions we need to answer.
Brief discussion about why we are adding regular expressions to the standard. "People love them, at least some of them".
Rok asked is there a reasonable subset that we could adopt? General agreement that this would be worthwhile. Mike resolves that Waldemar should edit the document for its next iteration. It doesn't appear to make sense to merge into the base document until then.
Waldemar posted a document [from Michael Ang] to Mike C's site.
He explains that we want to differ from Java for escapes. Not sure if we want to allow escapes in identifiers. Escapes provide a means for people to enter characters that aren't available on their keyboards. We are certain that this is a real need. Therefore it appears we do need to allow escapes in identifiers.
Java 1.1.7 allows the Euro sign where ever it allows the Dollar sign. The Euro is not in Unicode 2.0, but is in Unicode 2.1. What should we do?
Mike C. proposes that we pass Waldemar's document to the I18N subgroup to work on.
15.x HasInstance, etc. [MM]
Herman has suggested changing the algorithm to a do-while loop to omit the case where the object is its own prototype. Mike C. resolves that we have agreement to make the change. Bill has already merged the other changes into the base document.
Clayton: let's not do it in the standard! Herman agrees that its a hard problem to do right. Chris says it looks like something we should defer. Waldemar, would like instead to work on ways to work on computer readable formatting library. We have already agreed to defer toSource which was intended to be the vehicle for persistence.
Deferred!
Feb 19th hosted by Netscape.
Exceptions and run-time errors.
URI encode and decode - owner needed
We next chose to pick off some more of the issues relating to modularity.
Chris wants to talk about method overloading
Waldemar proposes to talk about the set of primitive types and types of literals.
When calling to an overloaded in Java, the work is done in Java. In effect you map the overloaded methods into a single entry point to code which dispatches appropriately.
Chris draws on the whiteboard:
function size (x:String)
{
return x.length;
}
// the following may be in a different package
function size (x:Array)
{
return x.arraySize();
}
function size (x:Window)
{
return x.length * y.length;
}
size("hello");
size("new Array( ... ));
size(new Window( ));
For single argument functions, it is similar to dispatching on the class. When there are multiple arguments, there is a notion of the most specific match. There are several approaches to matching. If the result is ambigous, it is appropriate to throw an error.
Bill proposes there may be ways based upon static type declarations that quickly allow you to rule out certain choices. He thinks that estimating the cost of conversion of argument types may be too expensive.
Rok asks whether local functions hide functions in other packages? This is a question of scoping rules.
Herman is inclined to restrict overloading to within classes. Rok would like what happens with functions to also apply to global variables. Waldemar is also skeptical about overloading. Herman draws an analogy between classes and packages. Chris refutes this.
One compromise is that you can only overload functions in the same package.
Chris reports that most cases the dispatch is on a single argument and similar in efficiency to inheritance and virtual methods. For dispatch based upon multiple arguments the cost rises incrementally.
Waldemar suggests you get much of the same power by subclassing and that overloading makes programs more fragile. For instance, if some of the overloaded methods are in some classes and others are in superclasses. However, the same thing also arises as a consequence of virtual methods.
Herman cannot see any compelling arguments as why not to allow overloading. He explained how by moving dispatch into the language you can do a better job using information in the call site than a programmer would do by writing a single function with explicit dispatch code.
We are really talking about whether we are dispatching on more than one argument, i.e. multimethods. There are ways of sealing it off, but this would result in complicating the language.
Action: Chris to write up a detailed exploration of the alternatives and their consequences.