Dave
Waldemar
Richard
Chris
Herman
Mike C
Jeff
Peter
Clayton
Andrew
Sam
Dario
Mike M
See Mike's agenda.
Mike reminds subgroup leaders to be sure to confirm dates for their subgroup meetings. There was some confusion over the recent I18N/Modularity meetings
Date of 1st meeting for Subset group (WAP convergence). Tom Greene proposed December and January. HP folks want to avoid December. Dave would like to align the meeting to occur directly before or after the main ECMAScript meeting.
We propose 1st choice 24-25th, 2nd 11-12th or 12-13th January, 3nd choice 19th-20th. The location is settled to be in the Bay area - Netscape.
Some editorial issues. Monica Broxner (ECMA Secretary) reports problems with word: selecint heading 1 resulted in all numbers disappearing. Applying "Times New Roman" to paragraphs caused all italics, bold and special scripts to disappear. Andrew offers to chase up some help.
Waldemar circulates a small handout describing some corrections:
In 8.6.2 (Internal Properties and Methods) (every object must implement the prototype property. In section 15 (Native ECMAScript Objects), Waldemar proposes adding "Unless otherwise specified the [[Class]] property of a built-in object is "Function". In 15.4.4 (Properties of the Array Prototype Object), he wants to add the [[Class]] is "Array". In 15.10.6 (Properties of the RegExp Prototype Object) he proposes we add the sentence: The value of the internal [[Class]] property of the RegExp prototype object is "Object". He also asks about the constructor property of the Math object. We agree to change it to "Math". Thanks to Herman for raising this one.
We agree to the proposed changes.
Andrew says that Microsoft tripped over a difference in the implementations for String.replace() and how it relates to regular expressions. Changing to the edition 3 definition broke a number of pages (including the microsoft site). Waldemar says he prefers the old Microsoft behavior.
Mike proposes we provisionally change the standard (E3) to reflect the Microsoft behavior, conditional on customer feedback. Another possibility would be to make this implementation dependent and deprecate it. We decided to go with the former approach.
"AAA*" .replace("A*, "B") --> "AAB" .replace(/A*/, "B") --> "B*"
Waldemar will change 15.5.4.11 to reflect the Microsoft behavior. If the first argument is not a string, call toString on it.
The description of the I18N library should be normative in E4.
Dave proposes we add fat strings or "here documents" to the misc. enhancements. The technique specifies a substring as terminator and avoids need to escaping special chars within the fat string. Tentatively agreed.
Modularity - we will leave the full feature list to the modularity subgroup.
Catch guards - Mike proposes we keep this but drop exceptions and run-time errors since we have dealt with these in E3.
Atomic (thread-safe) operations. We may defer this to the future (E5), but we need to discuss this.
Declaration qualifiers - further discussion needed.
Extensible syntax e.g. # for RGB. - further discussion.
Units - ditto.
Here documents - we have just added this.
Conditional compilation dropped since it will be covered under E4. Generic sequence - leave for further discussion. I18N normative library dropped since it will be dealt with in E4.
We decide to drop Date and move it into the I18N possibly including a Calendar object for E4.
Binary large object (e.g. images) - we await a proposal. The Nombas company when they were in ECMA TC39 proposed the idea. We decide to leave this off the list.
We leave the rest as is.
Tentatively Sam will carry on the support for the ECMAScript site previously maintained by Mike. The revised futures document will be posted there: http://www2.hursley.ibm.com/tc39/
Richard thinks that Calendar object may now make it above the cut line. We defer the discussion of the I18N work to tomorrow morning
Dave says the meeting started by going over the decisions we thought we had made in the previous meeting. We ended by confirming the earlier decisions.
Andrew relays some feedback from Microsoft internal users about the name for "method" versus "function". These users were dynamically generating classes. In summary these users felt that there wasn't sufficient justification for the change of name (some 350 responses on this point).
Sam proposes we allow both functions and methods, where function supports the older looser calling semantics. Dario doesn't like the idea of supporting both old and new call semantics.
Herman notes he had problems explaining the difference between function and method. He probably doesn't understand the differences, he says. Sam gives his understanding.
Dario thinks that backwards compatibility is not the main priority. You want to use better syntax for classes.
What is the distinction between a function inside and outside a class wrapper?
Chris notes that existing code will continue to work, but if people want to start using true classes, then they will expect to have to make some changes.
Mike proposes we have secure and insecure functions and make the switch at the class level.
In discussion, we realise that we have 2 groups of users those who bring their experience with Java to how they expect to see classes written, and those who only know ECMAScript. The latter will have certain expectations about how functions work.
If you learned object oriented programming, you currently have to fake it in ECMAScript. You really want a cleaner syntax. If you wrap class around function, you want function to have the semantics of methods.
Dave wants functions outside classes to also work the way you expect from other languages, e.g. fixed number of arguments and dynamic dispatch on argument types, with the ability to designate an old style function as needed.
Mike gives an interesting historical account of how number systems appeared and evolved.
IBM's Java implementation and specification of the ANSI decimal number package is available free from http://www2.hursley.ibm.com/decimal. A freelance software developer in Belgium has an alternative implementation. There are already free implementations available as C source.
The proposal relies on a MathContext class for carrying the additional contextual information that is needed in addition to the numbers themselves. This covers the precision, the exponential notation (ENGINEERING, PLAIN or SCIENTIFIC), the rounding mode (e.g., ROUND_HALF_UP), and a flag for extra checking (lostDigits).
Mike proposes we switch the ECMAScript Number class to use decimal numbers. This meets with general approval, although Waldemar notes his preference for treating decimal numbers as a library. Mike responds, saying that it is essential to make decimals the default rather than the option if you are to meet the expectations of most users.
Clayton draws up a diagram characterising the user base:
App building is where you use scripting to glue several things together, but don't use the client-server model.
Most programs, the dominant cost is call-overhead, so any additional cost in decimal arithmetic is unimportant. Mike notes that calls to a database etc. will tend to be costly, but this is unrelated to the relative costs of decimal vs binary arithmetic.
We feel we would like Nan to be available rather than stopping execution in all cases. However, sometimes you will like to intercept the exceptions. This argues for the context mechanism to be supported rather than fixing the defaults. Mike says that it would be easy to add NaN and infinity to the decimal number system.
There are a number of possibilities for setting the number context, e.g., compilation unit, package or class.
Mike volunteers to see what parts of ECMA 262 will be touched by this. He asks for input from folks and plans to summarise in a future meeting (he probably won't be able to attend the January meeting).
Dinner plans! - The Yarrow Bay Grill 6:45pm, 1270 Carillon Point, Kirland, WA, 98033.
Richard gives us a handout describing common usage scenarios for number formatting and sorting. It includes some sample code to illustrate the ideas.
// use the default format output = value.toLocaleString(); // using some other locale output = value.toLocaleString(Locale("de-IT"); // specify 2 decimal places and comma for thousands output = NumberFormatter(value, "#,##0.00"); // in a loop var fm = NumberFormatter("#,##0.00"); for (value in values) output = fm.format(value);
The format pattern e.g. "#,##0.00" is not ideal since it doesn't generalize well. Waldemar proposes:
output = NumberFormatter(value, decimalPlaces:2, thousandsSeparator:true);
Peter notes that this would be closer to how VBScript supports number formatting. Dave suggests that creating an instance of a number formatter and then to tweak its properties seems like the natural approach.
Richard adds yes, that's how its done in Java. However, it's nice to have a shorthand for this. He also notes that when you create an instance of the number formatter in Java, you supply the locale, which sets the defaults appropriately.
Dario suggests you could instead ask the locale object for the corresponding number formatter. This could also be used to get the localize calendar object.
var fm = Locale("de-IT").getNumberFormatter(); fm.minFractionDigits = 4; fm.useThousandsSeparator = false; output = value.toFormattedString(fm);
Waldemar asks what holds the character for the thousands separator etc. Richard then entertains us with a description of the "spelled out" format for Chinese/Japanese numbers. Waldemar points out the last approach above suffers from a problem when adding new methods. You can't use subclassing.
Richard says he was thinking this could be implemented by passing the formatting request through to Java or Win32 etc. Herman notes we need to distinguish the geographical region from cultural specific behavior. The single notion of locale doesn't quite capture this.
We agree that there is a locale object which identifies a culture and a region. It contains factory objects for the date and number formatter etc. We may want to allow for personalized locales, e.g. number formatting for Swiss German Physicists.
Richard is strongly against using a global variable for the locale. Waldemar notes the problems this has caused for C++. Peter, on the other hand, doesn't like the idea of passing the locale or number formatter around a lot.
We then turned to sorting. This has largely been covered before, and we have little to add to what Richard has written.
Richard floats the idea of a Collection class. This would simplify the I18N library. For example, a function which takes an array, and a function, and applies the function to each member of the array, placing the result into an output array. We encourage Richard to write up a proposal.
Mike puts up a diagram describing how he sees the process:
GA <--- TC39 ---> Guidelines and scope ^ | | v Feedback Modularity Subgroup (MSG) ^ | | v Users <----- Design
Retain simplicity (readability, accessibility for novices, consistency)
Don't make it too much like Java (complexity, wordiness)
Don't lose flavo[u]r - simple syntax, readability, ability to omit needless declarations, keep semicolon insertion (stridently voiced feedback)
Keep language dynamic - anything you can do statically, you can do dynamically - create functions, classes, ornament objects etc.
Upwards compatible - keep prototypes and parent access
One person said don't add classes
Going down the Java/C++ way makes good sense i.e. don't diverge unnecessarily from Java - this probably relates mostly to syntax
Don't mess too much with the language (evolution not revolution) - ability to incrementally improve code
No step functions please!
Minimise surprised users
Faster and more robust (bigger programs)
Give us packages!
Mike summarises what we see as the motivation for change:
We will review whether to fold the Modularity subgroup into the main group in the January meeting.
Peter described the survey.
Herman wants us to resolve on the class syntax issue: vis to use the following:
class C { var a, b, c; // instance variables static var d, e; // class variables // Declare instance method foo function foo (...) { ... } // declare class method bar static function bar (...) { ... } }
Waldemar cites class and instance constants as a problem. He draws up a table of a range of alternatives.
Dave proposes we allow this to be passed to functions outside a class definition independently of whether varargs is enabled or not.
Waldemar and Herman state they think they have common ground. We now try to elucidate this.
[strict] [static|instance|lenient] function foo () or [strict|lenient] [static|instance] function
What do these modifiers mean for functions declared inside or outside a class, and what are the defaults?
All instance functions within a class are strict by default (proposed by Dave and Dario). In in other words, when a function is called its signature matches the arguments supplied.
Herman would like to deprecate the arguments object for functions within classes.
Waldemar proposes that if you call a strict function with the wrong number of arguments, an error is thrown. Herman says the exact behavior depends on the way the function is declared. Error recovery could be implementation dependent. Herman adds even in lenient mode you want a warning, in strict mode you want an error.
What is the default mode for functions within classes - strict or lenient? Mike M. says that if you don't raise an error when calling a strict function with the wrong number of arguments, then method overloading will be precluded.
strict mode: function f() {...} lenient mode: f(1, 3); // throws an error
same situation but reverse roles
lenient mode: function f() {...} strict mode: f(1, 3); // doesn't throw an error
Waldemar then asks for what is the default mode (Strict or lenient) for unadorned method functions?
lenient mode: class foo { function f() { // "this" is guaranteed to be // an instance of class foo // or a subtype of foo } } a = new foo; a.f(1,3); // throws an error!
Chris proposes we allow functions to be declared as lenient, i.e. accept old style calls with variable number of arguments.
Waldemar and Herman agree to:
function f(a, b, ...) { // the 3rd argument is not accessible }
We also agree to the following, although Chris would like to see "args..." rather than "...args".
function f(a, b, ...args) { // the 3rd argument is accessible via args }
Herman doesn't like the existing E3 arguments object!
Herman likes Waldemar's proposal for passing named arguments saying this is a good fit to his needs (MS office). Waldemar's proposed syntax is:
f(17, 5, x:3)
The named arguments would be available via the args array. The exact syntax is not settled. Herman and Peter will look into the details and eventually come back with a proposal. Herman adds, this is currently a low priority compared with other features.
Waldemar proposes a means for defining default values for missing arguments.
function f(a, b=0, ...args) { }
where b defaults to zero.
Clayton suggests we return to what the "instance" modifier would mean. Herman wants to rule out executable code within classes. He wants the contents of a class to be limited to var, function or a nested class.
An open issue is the syntax for constructors - can you choose this or is it limited to the name of the class?
Andrew proposes to work with Clayton and Dave to plan a further user study to check our evolving design choices.