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. On Fri, Mar 8, 2013 at 5:25 PM, Brendan Eich <[email protected]> wrote: > 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 <[email protected]<mailto: >> [email protected]>> 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<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 >>> <[email protected] <mailto:[email protected]>**> 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 >>>> <[email protected] <mailto:[email protected]>**> 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<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 >>>> [email protected] <mailto:[email protected]**> >>>> >>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>>> >>>> >>>> >>> >>> >>> >>> ______________________________**_________________ >>> es-discuss mailing list >>> [email protected] <mailto:[email protected]**> >>> >>> https://mail.mozilla.org/**listinfo/es-discuss<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 >> [email protected] <mailto:[email protected]**> >> >> >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> >> >> ______________________________**_________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
