Discuss
  • Lastest ES6 draft (rev 14) now available

Lastest ES6 draft (rev 14) now available

# Allen Wirfs-Brock (13 years ago)

The March 8, 2013 Rev 14 draft is now available at the usual place: harmony:specification_drafts

Changes include:

Class bodies are now always string static methods may now be defined in ClassBody Updated comprehension syntax to use left-to-right order Eliminated is and isnt operators added grammar productions to allow unqualified super to be used after new operator expression to the right of of in for-of now restricted to being AssignmentExpression Almost all Chapter 15 constructors are now specified to have an @@create methid and are initialized in a manner that supports subclassing. (still need to work on Function) Added Object.getOwnPropertyKeys function Added Object.is function Tentatively added Object.mixin function Array.from now takes an optional map function Added String.prototype.normalize method All String.prototype methods that accept RegExp arguments will now work with subclasses of RegExp Renamed Number.prototype.toInt to Number.prototype.toInteger RegExp global, ignoreCase, multiline, source, sticky are now prototype accessor properties rather than instance own data properties. This is needed to support adding web compatible compile method. Added new RegExp.prototype methods that allow string methods to work with RegExp subclasses: match, replace, search, split, @@isRegExp Map and Set constructors now accept a =n optional comparator parameter. Only value currently allowed is “is” ArrayBuffer and TypedArray object length no long restricted to 232 limit Eliminated all remaining references to [[Class]] and [[NativeBrand]] (except for in some DataView code that needs rewritting anyway) Added SameValueZero abstraction operation that considers -0 and +0 to be the same value. Rename [[GetP]] to [[Get]] and [[SetP]] to [[Set]] Specified that unless otherwise indicated, internal data properties are created when an object is allocated. Internal data properties are now explicitly listed in ObjectCreate abstract operation calls. internally consolidated [[IsExtensible]]/[[IsSealed]/[[IsFrozen]] and [[PreventExtensions]]/[[Seal]]/[[Freeze]] into two MOP operations [[HasIntegrity]] and [[SetIntegrity]]. However, no public APIs (Proxy traps and Reflect functions) changed. Numerous editorial and technical corrections, clarifications, and bug fixes

# Allen Wirfs-Brock (13 years ago)

The March 8, 2013 Rev 14 draft is now available at the usual place: harmony:specification_drafts

Changes include:

Class bodies are now always string static methods may now be defined in ClassBody Updated comprehension syntax to use left-to-right order Eliminated is and isnt operators added grammar productions to allow unqualified super to be used after new operator expression to the right of of in for-of now restricted to being AssignmentExpression Almost all Chapter 15 constructors are now specified to have an @@create methid and are initialized in a manner that supports subclassing. (still need to work on Function) Added Object.getOwnPropertyKeys function Added Object.is function Tentatively added Object.mixin function Array.from now takes an optional map function Added String.prototype.normalize method All String.prototype methods that accept RegExp arguments will now work with subclasses of RegExp Renamed Number.prototype.toInt to Number.prototype.toInteger RegExp global, ignoreCase, multiline, source, sticky are now prototype accessor properties rather than instance own data properties. This is needed to support adding web compatible compile method. Added new RegExp.prototype methods that allow string methods to work with RegExp subclasses: match, replace, search, split, @@isRegExp Map and Set constructors now accept a =n optional comparator parameter. Only value currently allowed is “is” ArrayBuffer and TypedArray object length no long restricted to 232 limit Eliminated all remaining references to [[Class]] and [[NativeBrand]] (except for in some DataView code that needs rewritting anyway) Added SameValueZero abstraction operation that considers -0 and +0 to be the same value. Rename [[GetP]] to [[Get]] and [[SetP]] to [[Set]] Specified that unless otherwise indicated, internal data properties are created when an object is allocated. Internal data properties are now explicitly listed in ObjectCreate abstract operation calls. internally consolidated [[IsExtensible]]/[[IsSealed]/[[IsFrozen]] and [[PreventExtensions]]/[[Seal]]/[[Freeze]] into two MOP operations [[HasIntegrity]] and [[SetIntegrity]]. However, no public APIs (Proxy traps and Reflect functions) changed. Numerous editorial and technical corrections, clarifications, and bug fixes

# Andrea Giammarchi (13 years ago)

am I understanding mixin correctly?

'mixin' in Object || (Object.mixin = function mixin( target, source ) { for(var keys = Object.getOwnPropertyNames(source), i = keys.length; i--; Object.defineProperty( target, keys[i], Object.getOwnPropertyDescriptor( source, keys[i] ) ) ); return target; });

# Andrea Giammarchi (13 years ago)

also .. how that happened that Array.from is basically the equivalent of

Array.from = Function.call.bind(Array.prototype.map); ?

Wasn't the initial reason to Array.from avoid the repeated all over everywhere [].slice.call(arguments) where a signature slice-alike would be more suitable so instead of Array.from(arguments).slice(1), as example, one would Array.from(arguments, 1) ?

Thanks again :-)

# Rick Waldron (13 years ago)

On Fri, Mar 8, 2013 at 6:31 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:

also .. how that happened that Array.from is basically the equivalent of

Array.from = Function.call.bind(Array.prototype.map); ?

Wasn't the initial reason to Array.from avoid the repeated all over everywhere [].slice.call(arguments) where a signature slice-alike would be more suitable so instead of Array.from(arguments).slice(1), as example, one would Array.from(arguments, 1) ?

The addition of a "map callback" is to give subclasses, that inherit Array.from() a way of creating new "collection likes", of their own type. You wouldn't want subclasses to return the parent classes type:

class Vector extends Array {}

Vector.from( ... ) // I want a new Vector, not an Array.

The example I gave during Allen's presentation:

var nodelist = NodeList.from(["div"], nodeName =>

document.createElement(nodeName) );

Full discussion: rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#48-refactored-new-operator-and-the-create-method(search for "Conclusion/Resolution, Bullet 2")

The proposed and accepted solution: rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md#revising

# Allen Wirfs-Brock (13 years ago)

not exactly, you'd have to use getOwnPropertyKeys rather than getOwnPropertyNames. Also it "rebinds" super references to from source object to target objects.

# Andrea Giammarchi (13 years ago)

I see, cool stuff then, I've missed that thanks.

# Andrea Giammarchi (13 years ago)

getOwnPropertyKeys isn't shimmable, since there's no way to understand a symbol in ES5, correct? In that case Object.keys() ain't mixin enough, getOwnPropertyNames looks like the best option (which AFAIT will act as getOwnPropertyKeys where only getOwnPropertyNames is available since Symbols won't be implemented)

Same stuff is the super, I cannot simulate without caller that, I did successfully with (the name might mislead) poo.js though: WebReflection/poo#poojs

Too bad I cannot have caller and I wonder how transpilers gonna implement that since it's needed at runtime.

Thanks Again, please correct me everywhere I am wrong if you have time

# Brandon Benvie (13 years ago)

On 3/8/2013 4:03 PM, Andrea Giammarchi wrote:

getOwnPropertyKeys isn't shimmable, since there's no way to understand a symbol in ES5, correct? In that case Object.keys() ain't mixin enough, getOwnPropertyNames looks like the best option (which AFAIT will act as getOwnPropertyKeys where only getOwnPropertyNames is available since Symbols won't be implemented)

Same stuff is the super, I cannot simulate without caller that, I did successfully with (the name might mislead) poo.js though: WebReflection/poo#poojs

Too bad I cannot have caller and I wonder how transpilers gonna implement that since it's needed at runtime.

Thanks Again, please correct me everywhere I am wrong if you have time

On Fri, Mar 8, 2013 at 3:55 PM, Allen Wirfs-Brock <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:

not exactly, you'd have to use getOwnPropertyKeys rather than
getOwnPropertyNames.  Also it "rebinds" super references to from
source object to target objects.

On Mar 8, 2013, at 3:26 PM, Andrea Giammarchi wrote:

am I understanding mixin correctly?

'mixin' in Object || (Object.mixin = function mixin(
  target, source
) {
  for(var
    keys = Object.getOwnPropertyNames(source),
    i = keys.length; i--; Object.defineProperty(
      target,
      keys[i],
      Object.getOwnPropertyDescriptor(
        source,
        keys[i]
      )
    )
  );
  return target;
});

thanks


On Fri, Mar 8, 2013 at 2:35 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:

    The March 8, 2013 Rev 14 draft is now available at the usual
    place:
    http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts


    Changes include:

     *
        Class bodies are now always string
     *
        *static* methods may now be defined in /ClassBody/
     *
        Updated comprehension syntax to use left-to-right order
     *
        Eliminated *is* and *isnt* operators
     *
        added grammar productions to allow unqualified super to
        be used after new operator
     *
        expression to the right of *of* in *for-of* now
        restricted to being /AssignmentExpression/
     *
        Almost all Chapter 15 constructors are now specified to
        have an @@create methid and are initialized in a manner
        that supports subclassing. (still need to work on Function)
     *
        Added Object.getOwnPropertyKeys function
     *
        Added Object.is <http://Object.is/> function
     *
        Tentatively added Object.mixin function
     *
        Array.from now takes an optional map function
     *
        Added String.prototype.normalize method
     *
        All String.prototype methods that accept RegExp arguments
        will now work with subclasses of RegExp
     *
        Renamed Number.prototype.toInt to Number.prototype.toInteger
     *
        RegExp global, ignoreCase, multiline, source, sticky are
        now prototype accessor properties rather than instance
        own data properties. This is needed to support adding web
        compatible compile method.
     *
        Added new RegExp.prototype methods that allow string
        methods to work with RegExp subclasses: match, replace,
        search, split, @@isRegExp
     *
        Map and Set constructors now accept a =n optional
        comparator parameter. Only value currently allowed is "is"
     *
        ArrayBuffer and /Typed/Array object length no long
        restricted to 2^32 limit
     *
        Eliminated all remaining references to [[Class]] and
        [[NativeBrand]] (except for in some DataView code that
        needs rewritting anyway)
     *
        Added SameValueZero abstraction operation that considers
        -0 and +0 to be the same value.
     *
        Rename [[GetP]] to [[Get]] and [[SetP]] to [[Set]]
     *
        Specified that unless otherwise indicated, internal data
        properties are created when an object is allocated.
        Internal data properties are now explicitly listed in
        ObjectCreate abstract operation calls.
     *
        internally consolidated
        [[IsExtensible]]/[[IsSealed]/[[IsFrozen]] and
        [[PreventExtensions]]/[[Seal]]/[[Freeze]] into two MOP
        operations [[HasIntegrity]] and [[SetIntegrity]].
        However, no public APIs (Proxy traps and Reflect
        functions) changed.
     *
        Numerous editorial and technical corrections,
        clarifications, and bug fixes



    _______________________________________________
    es-discuss mailing list
    es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
    https://mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

Classes in general aren't straight transpilable to ES6. Not faithfully. Part of their contract is that you can use them to extend builtins, for example. I'm sure there are other little details as well. It is possible to transpile all of ES6 to ES3 though if you're willing to write a runtime and convert all operators to function calls that use the runtime to implement the delta between ES6 and ES3.

# Andrea Giammarchi (13 years ago)

I think you just described Dart runtime ... :-)

I was thinking about transpilers since that is the TypeScript way which is a better one over CoffeeScript in my opinion but then generated code will be as slow as Dart JS runtime on mobile (specially Android 2.X hardware/software)

But if you guys draft stuff that cannot be even transpiled, how develoeprs are suppose to serve one or another file?

<script type="application/es6"></script>

?

# Brendan Eich (13 years ago)

Please stop dragging Dart into it, it's irrelevant.

Trans-compiling works for 99% use-cases that aren't extending built-ins.

# Domenic Denicola (13 years ago)

Trans-compiling works for 99% use-cases that aren't extending built-ins.

Or using class-side inheritance in a non-proto environment. (That's probably still within the 1%, admittedly.)

Also, I thought super was fairly magical? E.g. how it gets associated to methods? Not very sure though, this is just an impression based on the sheer volume of spec text written about super.

# Brendan Eich (13 years ago)

"Classes as sugar" was a good slogan and guiding design principle, but when one has to extend kernel semantics, it's best to do it and not (hold back | worry about the) fall into the Turing tarpit.

# Brandon Benvie (13 years ago)

On 3/8/2013 5:43 PM, Domenic Denicola wrote:

Trans-compiling works for 99% use-cases that aren't extending built-ins. Or using class-side inheritance in a non-proto environment. (That's probably still within the 1%, admittedly.)

Also, I thought super was fairly magical? E.g. how it gets associated to methods? Not very sure though, this is just an impression based on the sheer volume of spec text written about super.

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

You can transpile statics although, again, not entirely faithfully, by putting the statics on each of the inheriting constructors. Not quite the same...it's these "little details" I was referring to. They start to add up

# Domenic Denicola (13 years ago)

You can transpile statics although, again, not entirely faithfully, by putting the statics on each of the inheriting constructors. Not quite the same...it's these "little details" I was referring to. They start to add up

Agreed. I've been trying to file such little details against Traceur 1, but would welcome any efforts to enumerate them, since I think most people are of the impression that transpilation will solve the migration problem.

# Brandon Benvie (13 years ago)

On 3/8/2013 5:53 PM, Domenic Denicola wrote:

You can transpile statics although, again, not entirely faithfully, by putting the statics on each of the inheriting constructors. Not quite the same...it's these "little details" I was referring to. They start to add up Agreed. I've been trying to file such little details against Traceur 1, but would welcome any efforts to enumerate them, since I think most people are of the impression that transpilation will solve the migration problem.

If transpilation is to solve the issue then these differences need to be overcome, as you're attempting to help do. There can't be differences or you're going to see subtle, extremely hard to diagnose bugs when you move between actual ES6 environments and transpiled ES3/ES5 ones. I think ultimately the only really acceptable answer is to do what I said: create a runtime that implements the entire delta between ES3/ES5 (depending how brave the author is) and ES6 and converts all operators (including property access) to function calls that go through the augmented runtime. The problem is that this may or may not be very optimizable thus making it unusable in production for a different reason.

# Andrea Giammarchi (13 years ago)

I miss the "stop dragging" as if I've ever done it in es-discuss ... or was it more generic frustration I've never spotted here? I don't think I've said anything bad, we all know how Dart JS runtime works.

I wasn't blaming the language itself, and never done, I was underlying how it works after Brandon statement.

Now, how transpilers are going to solve Object.mixin super call? 'cause once again, that should be solved runtime and I am curious, without caller, how transpilers are thinking to solve that.

# Allen Wirfs-Brock (13 years ago)

On Mar 8, 2013, at 4:15 PM, Brandon Benvie wrote:

...

Classes in general aren't straight transpilable to ES6. Not faithfully. Part of their contract is that you can use them to extend builtins, for example. I'm sure there are other little details as well.

Actually, subclass built-ins isn't tied to using class declarations. It is more closely tied to extensions to the new operator (the default [[Construct]] internal method) so that JS code has more control over the allocation step via the @@create methods. You probably can't directly shim that but you could transpile it into equivalent semantics. You can also use Dunder proto and other hacka to hijack built-in array (and other exotic object) instances and return them from @@create methods with arbitrary [[Prototype]] values.

Class declaration themselves don't really create any object structures that you can't create using ES5 techniques plus Dunder proto. One thing it does that you can't accomplish in ES5 is create functions (for methods) aren't constructable. Also supporting super would require a transpiler.

# Brendan Eich (13 years ago)

Andrea Giammarchi wrote:

Now, how transpilers are going to solve Object.mixin super call? 'cause once again, that should be solved runtime and I am curious, without caller, how transpilers are thinking to solve that.

Do what you need to do (caller, LOL). We're talking about an interim technique. The long-term design has to count, too, and 99% solutions are often enough to bridge short to long term,

# Andrea Giammarchi (13 years ago)

which part is LOL about caller I don't get it and LOL as argument, from you, is more LOL than caller, IMO.

Sad to see this attitude 'cause I've raised a problem that cannot be transpired, what here and there many of you are convinced is the right thing to do in order to have graceful migration to new standards.

Best

# Brendan Eich (13 years ago)

Andrea Giammarchi wrote:

which part is LOL about caller I don't get it and LOL as argument, from you, is more LOL than caller, IMO.

Sad to see this attitude 'cause I've raised a problem that cannot be transpired, what here and there many of you are convinced is the right thing to do in order to have graceful migration to new standards.

You're not taking the point that languages grow their kernel semantics, which means not everything desugars to older versions via "transpilation". This is part of the Harmony

harmony:harmony

"Minimize the additional semantic state needed beyond ES5" does not mean "Minimize to zero".

Sorry for LOLs, I just think given the fact that some semantics are new must be accepted, and transpilers may have to work harder and at the edges be compilers with more complex runtimes. But as I tried to suggest, for most -- or let's say "much" -- code there's a simpler translation.

# Andrea Giammarchi (13 years ago)

my point is: with something deprecated via "use strict" I could simulate a behavior that is not possible to simulate anymore with the "new language features"

Usually, above concept, is called "step backward" and I am interested into polyfills able to work 100% 'cause developers are kinda "scared" these days to adopt weird solutions that simply works, or new standards that no polyfill can make.

Nothing more than this