March 29 meeting notes

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Mar 29 20:30:35 PDT 2012


I don't think the report on maximally minimal classes fully reflections the discussion:

> Maximally minimal classes:

Alex and Allen initiated the discussion as a status up-date to TC-39..  We pointed out that this proposal had recently been extensively discussed on es-discuss and that it appear to have considerable support from most of the participants in that discussion.  

> Luke:  These aren't good enough to be a net win.

I'm not sure whether this is an exact quote.  Luke certainly did raise the issue of whether classes, as defined by this proposal, added enough functionality to ES to justify the inherent complexity of a new feature.

Allen and Alex reiterated that this proposal is only trying to address the most common class definition use cases but in a way that allows for future extensions to address a broader range of use cases. These is significant value in what the proposal provides even if it doesn't do everything any might want.

dherman stated he has some minor design issues he wants to further discuss, but that overall the level of functionality in this proposal was useful and would be a positive addition. He supports it.

> Waldemar:  These don't address the hard problems we need to solve.
> Concerned about both future-hostility (making it cumbersome for future
> classes to declare, say, object layout without cumbersome syntax by
> taking over, say, const syntax) and putting developers into a quandry

We discussed this concern quite a bit and did not identify any specify ways in which the current proposal would block future extensions.  Waldemar was asked to provide specific examples if he comes up with any.   Allen pointed out that future syntactic additions can also enforce new semantics.  For example addition of a per instance state declarations and a  "const" keyword to the constructor declaration could cause ad hoc this.property assignments to be statically rejected, if that was a desired semantics.

> -- if they want to do anything more sophisticated, they'll need to
> refactor their code base away from these classes.  Unless one choice
> is clearly superior, having two choices (traditional and extended
> object literals) is better than having three (traditional, extended
> object literals, and minimal classes).  Minimal classes currently
> don't carry their weight over extended object literals.  Perhaps they
> can evolve into something that carries its weight, but it would be
> more than just bikeshedding.

The above is a statement of Waldemar's opinion. Other opinions expressed in the discussion aren't record in the original notes.   

> Alex:  We need to do something.

Allen and Alex also expressed that it is unlikely that any class proposal that significantly goes beyond will be accepted for ES6.

> Debated without resolution.

In summary:

Waldemar should identify any specific ways that the syntax or semantics of this proposal would be future hostile.

Waldemar, Luke, and MarkM expressed varying levels of concern as to whether the user benefit of the proposal was sufficient to justify its inclusion. In order to resolve this question, both sides of the issue really need to provide better supporting evidence for the next meeting.

Allen

n Mar 29, 2012, at 5:02 PM, Waldemar Horwat wrote:

> Rough notes from today's meeting.
> 
>    Waldemar
> 
> -------
> ES 5.1 quirks in defining globals when the global object's prototype
> already contains a property with the same name:
> https://bugs.ecmascript.org/show_bug.cgi?id=78
> Waldemar: What if the prototype contains a getter or setter?
> Doesn't matter for the purpose of defining globals.
> Agreed on the solution proposed in the bug.
> 
> John: Do we have a process for tracking ES5.1 errata?
> Allen: Yes.
> John: WIll try to get an official errata on the ECMA site.
> 
> Strict function caller leak:  https://bugs.ecmascript.org/show_bug.cgi?id=310
> We should correct this in the errata.  MarkM might have more comments
> but he's not here.
> 
> Luke:  15.10.4.1 Regexp.source on empty regexps on all browsers
> returns the empty string instead of (?:), which is incompatible with
> the spec text.  That was a change to the spec in ES5 but browsers
> didn't obey it.
> Allen, Waldemar:  This isn't a spec bug.  It was an intentional change.
> Luke:  It breaks prototype.js.
> DaveH:  If this is the only breakage, change the spec to insert the
> regexp source into /(?: and )/ instead of / and /.
> Waldemar:  It's not the only problem.  Escaping of slashes is also a
> problem here.
> Luke:  Browsers diverge here.  Firefox is the only browser that does escaping.
> Debated.
> No consensus.
> 
> David Fugate:  Test262 update slideshow
> Microsoft sources now include ECMA copyright boilerplate instead of Microsoft's.
> MarkM will do likewise for Google sources.
> 19 new bugs
> 26 bugs resolved
> Prepopulated bug reports
> International402 mini-suite framework now (quietly) live, with one fake test
> Bill Ticehurst will replace David Fugate's role on Test262.
> Development focus will shift to ES6 tests.
> Allen: Section numbers will change in ES6, which will impact test
> suite organization.
> 
> Norbert:  Internationalization
> Final draft won't make it for June.  Will try for December.  Allen
> reviewed half of the spec and had lots of substantial comments.  There
> are quite a number of fixes that need to be made to the spec.
> Discussion about implementations and overspecification vs. underspecification.
> 
> MarkM: Quick follow-up on TCP correspondence from yesterday.  What
> should var do?
> MarkM proposed that var be statically rejected if it would cross a
> closure boundary.
> Waldemar: Since we gave up on TCP, => should work just like a function
> except for 'this'.
> Discussion cut off by Luke, since it looks like it won't be a quick one.
> 
> Discussion of hypot, hypot2.
> hypot is the square root of the sum of squares and takes either two or
> three arguments.
> hypot2 is the sum of squares and takes either two or three arguments.
> Waldemar: How is hypot2 better than just doing x*x + y*y?
> Luke: It's just ergonomics.
> General reluctance about the hypot2 name because it looks like the 2
> means two arguments (as in atan2).  Some debate about other function
> names (hypotSq? sumOfSquares?).
> MarkM: How is hypot better than sqrt(x*x + y*y)?
> It's potentially more efficient and more accurate.  It is widespread
> in numeric libraries.
> Consensus:  hypot will support just two or three arguments.  hypot2 dropped.
> Waldemar, MarkM:  Why not one or zero arguments?  It would be 0 for
> zero arguments and abs for one argument.
> Allen, DaveH:  If you pass one argument to hypot, you'll get NaN.
> Luke:  It's not variadic.
> Waldemar:  Why isn't it variadic?
> Luke:  2 or 3 is the 99% use case.
> Waldemar:  2 or 3 arguments is the 99% use case for max.
> Waldemar:  If it's not variadic and takes only 2 or 3 arguments,
> you'll get silent mistakes.  If you pass in four arguments, you'll get
> the hypot of the first three, and the last one will be silently
> ignored.  That's bad.
> Luke:  Will go back to the experts to explore implementing variadic hypot.
> 
> Add parseInt and parseFloat to Number, matching isNaN and isFinite?
> Use the name Number.parse instead of Number.parseFloat?
> Should these functions be specified as independent functions from the
> existing global parseInt and parseFloat, or should they be the same
> function objects?
> Consensus:  Not duplicting parseInt and parseFloat into Number.  May
> consider doing a Number.parse in the future.
> 
> Math.cbrt cube root:  Handles negatives, more accurate than pow.
> Approved.
> 
> Naming:  Math.sign vs. Math.signum?
> Sticking with Math.sign.
> 
> Should the spec try to enforce accuracy?
> No.  None of the existing math libraries spec accuracy.
> 
> MIN_VALUE is 0 on ARM implementations because they don't represent
> denorms.  This is a severe spec violation.  However, apparently
> turning off denorms is a major power savings on ARM.
> Allen, Waldemar: MIN_VALUE must be a nonzero value.  If a platform
> doesn't represent denorms, it should make MIN_VALUE be the smallest
> positive normalized number on that platform.
> 
> Number.toInteger:  Just does the internal ToInteger.  Not the same as floor.
> Renamed it to toInt.
> 
> Count leading zeros:  Number.clz.
> Consensus that we want it.
> Should we include "32" in the name?
> Waldemar:  "32" not needed in name.  None of the other bit operators
> include "32" in the name.
> MarkM:  Prefers clz32 but doesn't feel strongly.
> 
> Hex floating point literals:
> Waldemar:  Other languages include these things.  They're rarely used
> but when you want one, you really want one.  Use cases are similar to
> that of hex literals.
> Will explore adding them.
> MarkM:  0x3.p1 currently evaluates to undefined.  This would be a
> breaking change.
> Waldemar:  Not clear anyone would notice.  How did other languages
> deal with this?
> 
> Relocated and rescheduled meetings:
> May 21-23 Mozilla, Mountain View  (May 21 is internationalization)
> Sep 25-26 Northeastern, Boston
> The July and November meetings are the same are previously scheduled.
> 
> DaveH's presentation about module loaders
> Discussion about cross-origin problems and modeling iframes
> About loader providing a function to define the entire set of built-ins:
> Allen:  A lot of intrinsics refer to the built-ins.  The above
> function defines the ones that ECMAScript knows about.  What about
> other, implementation-specific ones?  Have the environment provide a
> way for making environments that include such things?
> Luke:  Objections related to WebIDL [I didn't follow the logic]
> Discussion about the role ECMAScript should play in the hierarchy of
> web infrastructure.
> 
> Waldemar: Is there any notion of a parent environment, other than
> whatever environment intrinsics get the built-ins from?  (quietly
> hoping the answer is no)
> DaveH:  No.
> Waldemar: What about the dynamic craziness related to inner and outer
> window objects?
> DaveH:  Will need extra hooks for that.
> 
> Waldemar:  What creates new intrinsic worlds?
> DaveH:  Creating a Loader does, as in:
> l = new Loader(System, {intrinsics: null});  // Can also specify
> existing intrinsics to share a world
> a = l.eval("[]");
> Object.getPrototypeOf(a) != Array.prototype
> b = l.eval("[]");
> Object.getPrototypeOf(b) != Array.prototype
> Object.getPrototypeOf(b) === Object.getPrototypeOf(a)
> 
> Allen: Can DefineBuiltIns be called any time?
> DaveH: It can be called on any object at any time.  Don't want to get
> now into esoterica of what happens if there are existing properties,
> setters, etc.
> 
> DaveH: Imperative module replacement example:
> @websockets exists as version 1.  An implementation wants to improve it to v2:
> import "@websockets" as ws;
> System.set("@websockets", polyfills(ws));
> 
> Waldemar:  What can you provide to the intrinsics parameter of the
> Loader constructor, other than the previously covered examples of null
> and another Loader?
> DaveH:  Nothing else is allowed there.
> Waldemar, Luke:  Then we'll need a notion of a loader type just like
> we have a notion of an array type.  At some point we'll need to say
> what happens when you pass an object that inherits from a Loader, a
> proxied Loader, etc.
> 
> Module syntax alternatives:
> module x at "foo.js"
> module x = "foo.js"
> module "foo.js" as x
> module x at "foo.js"
> Don't have time to discuss these now.
> 
> Unicode presentation
> In some places ES5.1 treats unicode characters as arbitrary 16-bit
> chunks.  In other places it has special provisions for surrogate
> pairs.
> For much text processing it doesn't matter; either works.  The trouble
> points are:
> - Supplementary characters within source code identifiers
> - Regular expressions
> - String comparison
> - Case conversion
> 
> Norbert's alternatives:
> 1. UTF-32 strings
> 2. UTF-32 or UTF-16 strings
> Waldemar: Either of these would be nightmares because they'd provide
> two different ways of encoding the same supplementary character, and
> by Murphy's Law you'd get the wrong one at the most inconvenient time.
> Wasted a lot of time in Perl which has this problem.  A far better
> solution would be to keep representation as always UTF-16 and just fix
> the functions to understand UTF-16 better.
> Olivier:  For ECMAScript to adopt the UTF-32 model, you'd need an
> amazingly compelling reason that would blow all other ones out of the
> water.
> Consensus: No one wants UTF-32 strings.
> 
> Norbert's favored third option:  Stick with UTF-16, change functions
> to understand UTF-16.
> MarkM:  Careful about breaking compatibility!  Change functions or
> create new ones?
> 
> Regular expressions:
> /u mode that matches via UTF-16 code points instead of code units.
> /./ would match a code point; supplementaries can be in ranges.
> Clear that this must be done via a mode; this would break too much
> stuff without a mode such as /u.
> 
> Waldemar: Why not graphemes?
> Nebojša: The Unicode folks tried it; it became too difficult.
> 
> Case conversion UTF-16 fixes are uncontroversial?
> Waldemar:  Not so.  When designing ES3 we intentionally disabled some
> Unicode case conversions to avoid nasty surprises.  For example, we
> wanted /[a-z]/i to match only the ASCII letters.  Had we allowed the
> true Unicode conversions, this would also match the non-ASCII Turkish
> dotless lower-case i (ı) or upper-case dotted I(İ).  There were
> similar issues around ß expanding into SS.  How will we deal with
> situations like this with /u?
> 
> Make /u be the little red switch for:
> 1. Unicode code point semantics
> 2. Unicode based \d\D\w\W\b\B
> 3. Unicode case folding
> 4. Remove some/all identity escapes to allow \p, \X, \N
> 5. Don't match web reality?
> 
> Can we do only 1+3+4+5, without 2?
> Waldemar:  That makes no sense.  Given 3, you shouldn't expect \w to
> match the same characters as in non-/u mode because, at the least,
> /\w/i will match ı or İ.
> Consensus on doing 1+3+4+5.  2 needs discussion.
> 
> < and > will work as they do now on strings -- compare code units as
> unsigned 16-bit integers.
> trim:  There are currently no supplementary white space characters, so
> we can redefine it to support supplementary characters without
> breaking anything.
> toLowerCase and toUpperCase:  Safari already converts supplementary
> characters with apparently no ill effects.  Consensus on redefining
> these to work properly on supplementary characters.
> 
> Base the spec on Unicode 5.1.  Implementations will be permitted to
> support later versions if they choose.
> 
> String.fromCodePoint(cp0, cp1, ...)
> This accepts integers between 0 and 0x10FFFF.  If the integer is in
> the surrogate range, it will produce an unpaired surrogate.
> 
> String.prototype.codePointAt(pos)
> Here pos is the code *unit* position.  If it's the second surrogate of
> a pair or an unpaired starting surrogate, it will return the code unit
> of the surrogate.
> 
> String.prototype.[iterator]
> Should return code point strings (of length 1 or 2), not numbers.
> 
> Waldemar: Would also want an iterator for graphemes.
> DaveH: The default iterator should return code point substrings.
> 
> Code point escape:
> "\u{20BB7}" === "\uD842\uDFB7"
> V8 doesn't currently throw a syntax error for \u{, but that will get fixed.
> Exclude 0xD800-0xDFFF?  No.
> 
> Maximally minimal classes:
> Luke:  These aren't good enough to be a net win.
> Waldemar:  These don't address the hard problems we need to solve.
> Concerned about both future-hostility (making it cumbersome for future
> classes to declare, say, object layout without cumbersome syntax by
> taking over, say, const syntax) and putting developers into a quandry
> -- if they want to do anything more sophisticated, they'll need to
> refactor their code base away from these classes.  Unless one choice
> is clearly superior, having two choices (traditional and extended
> object literals) is better than having three (traditional, extended
> object literals, and minimal classes).  Minimal classes currently
> don't carry their weight over extended object literals.  Perhaps they
> can evolve into something that carries its weight, but it would be
> more than just bikeshedding.
> Alex:  We need to do something.
> Debated without resolution.
> 
> Discussion about events/asynchrony/observers.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 



More information about the es-discuss mailing list