Lastest ES6 draft (rev 14) now available

Brendan Eich brendan at mozilla.com
Fri Mar 8 17:25:55 PST 2013


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

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

/be

Andrea Giammarchi wrote:
> 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>
>
> ?
>
>
>
>
> On Fri, Mar 8, 2013 at 4:15 PM, Brandon Benvie <bbenvie at mozilla.com 
> <mailto:bbenvie at mozilla.com>> wrote:
>
>     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:
>>     https://github.com/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  <mailto:es-discuss at mozilla.org>
>>     https://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.
>
>     _______________________________________________
>     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
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list