New ES6 draft released

The lastest ES6 draft (Rev 33, Feb. 12, 2015) is now available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#february_12_2015_draft_rev_32 Changes include: Refactoring of module abstract operations to support module loader specifications Additional runtime declaratio

Re: ArrayBindingPattern disallows trailing comma when BindingRestElement is present

On Feb 12, 2015, at 7:01 PM, Michael Ficarra wrote: > Is there any reason why a trailing comma is not allowed in an > ArrayBindingPattern when it has a BindingRestElement? I noticed yesterday > that my parser was erroneously allowing these, but the inconsistency with > both ArrayLiterals and O

Re: ArrayBindingPattern disallows trailing comma when BindingRestElement is present

On Feb 13, 2015, at 11:37 AM, Michael Ficarra wrote: > Even given what Allen said? I'm indifferent toward it at this point. Allen is > right that it's not particularly useful to allow it, but disallowing it is > also inconsistent with all related productions. You can submit it, but I'll just m

feedback request, bug 3694 - ArrayBuffers, memmove, and signaling NaNs

It'd be interested if anybody has any thoughts on my proposed solution for https://bugs.ecmascript.org/show_bug.cgi?id=3694 Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: TemplateLiteral tagged with super

On Feb 13, 2015, at 4:56 PM, Domenic Denicola wrote: > What semantics would you propose for this extension? The semantics are obvious enough, it would be equivalent to: super(callsite, ...substitutionValues) But what would it be good for. Can anybody think of a practical use case for this?

Re: feedback request, bug 3694 - ArrayBuffers, memmove, and signaling NaNs

On Feb 13, 2015, at 5:13 PM, Filip Pizlo wrote: > Hi Allen, > > (Meta: I'm assuming you'd prefer an on-list discussion rather than more > comments in the bug?) > > I think it's sensible to say that TypedArray.prototype.set doesn't require > NaN canonicalization - or rather, that it forbids it

Re: ES6 grammar for for-loops

On Feb 17, 2015, at 3:34 PM, Brendan Eich wrote: > Cyrus Najmabadi wrote: >> >> Ok. Thanks for confirming our read of the grammar. Is this shown on any >> breaking changes list anywhere? >> > > It should be -- who is maintaining such a list? > > Cc'ing Oliver, I believe he found a `for (va

Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

On Feb 11, 2015, at 8:30 AM, Allen Wirfs-Brock wrote: > TC39 members were aware that changing to using ordinary objects as the > prototypes of the legacy built-ins was a breaking change (for example, it > changes the prototypes {}.toString value). What we agreed to do was to mak

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

On Feb 19, 2015, at 9:01 AM, Andrea Giammarchi wrote: > I think I do understand ... is this operation valid in ES6 ? > > `var oneTwoThree = Array.prototype.concat(1, 2, 3); // [1, 2, 3]` > > 'cause that was the initial concern, and as far as I understand that will > break. > > Or does it? Ye

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

On Feb 19, 2015, at 9:01 AM, Andrea Giammarchi wrote: > I think I do understand ... is this operation valid in ES6 ? > > `var oneTwoThree = Array.prototype.concat(1, 2, 3); // [1, 2, 3]` you would get: [Array.prototype, 1, 2, 3] That's what convinced me. allen ___

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

On Feb 19, 2015, at 12:09 PM, Andrea Giammarchi wrote: > if we'd like to have Array.empty, Function.empty, String.empty and friends, > what's wrong with having these as we always had already: as prototypes? Just to keep things focused. *.empty is not something that is on the table for ES6. It

Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)

On Feb 19, 2015, at 1:13 PM, Mark S. Miller wrote: > > > On Thu, Feb 19, 2015 at 12:56 PM, Allen Wirfs-Brock > wrote: > > On Feb 19, 2015, at 12:09 PM, Andrea Giammarchi wrote: > > > if we'd like to have Array.empty, Function.empty, String.empty and friend

ES6 Spec Release Candidate 1

The last ES6 draft is now available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#february_20_2015_rev_34_release_candidate_1 The is the Rev34 draft of February 20, 2015. This is release candidate 1. It is the draft that TC39 members will review before our TC39 member

Re: Possible bugs in 12.1.1 Early Errors of Identifier

It would be better to report these as bugs at bugs.ecmascript.org On Feb 19, 2015, at 10:13 PM, Shinji Ikari wrote: > The second section under 12.1.1 says: > IdentifierReference[Yield] : yield > > BindingIdentifier[Yield] : yield > > LabelIdentifier[Yield] : yield > > It is a Syntax Error if

Re: short-circuiting Array.prototype.reduce

On Feb 23, 2015, at 7:22 AM, Mark S. Miller wrote: > We still an an option open to us, that would merely compatibly remove a > restriction from the language rather than add a feature: Allow labels to > remain visible across function boundaries, or at least across arrow function > boundaries. T

A Declarative replacement for toMethod

Here is a new proposal for a declarative replacement for Function.prototype.toMethod which was dropped from ES6 earlier this year https://github.com/allenwb/ESideas/blob/master/dcltomethod.md I've added this to the agenda for next months TC39 meeting but pre-meeting discussion is welcomed right

Re: A Declarative replacement for toMethod

On Feb 23, 2015, at 2:44 PM, Brendan Eich wrote: > Minor wording nit-pick/question: > > In what sense is an operator form declarative? I get that it's not an API -- > special form is special ;-). But what's being declared if the only grammar > extension is to the expression grammar? > I know,

Re: A Declarative replacement for toMethod

On Feb 23, 2015, at 3:40 PM, Domenic Denicola wrote: > Allen and I have been discussing this on Twitter. I thought I’d bring my > thoughts to list to get them somewhere with less of a character limit. > > In general, I think this is a pretty nice syntax for authors. However, I'm > concerned th

Re: A Declarative replacement for toMethod

On Feb 23, 2015, at 4:24 PM, Brendan Eich wrote: > I wonder why we cannot have toMethod, in due course. You had suggested the > ES6 signature with a second parameter, with default value: > > Function.prototype.toMethod(homeObject, methodName = this.name); > > With a function.name spec'ed in E

Re: `new Set()` or `new Map()` with more than one argument

On Feb 24, 2015, at 5:52 AM, Axel Rauschmayer wrote: > I’ve accidentally created the wrong set a few times: > > ```js > let set = new Set('red', 'green', 'blue'); > // WRONG: same as new Set(['r', 'e', 'd']) > ``` > > Would it make sense to throw if either of the constructors `Set` and `Map

Re: Function "name" property

> On Feb 25, 2015, at 7:26 PM, Matthew Robb wrote: > > ... > ​I think it would be best to put more distance between the name property of a > function and it's binding​ (if any) to reduce any potential confusion. Making > it a symbol property and (also my opinion) making it writable would help

Re: Function "name" property

On Feb 26, 2015, at 4:10 AM, Leon Arnott wrote: > The twitter thread starts here: > https://twitter.com/getify/status/570614952605560838 and basically boils down > to the observation that this: > ``` > ({ f() { return f; }}.f()) /* ReferenceError (probably) */ > ``` > is not semantically identi

Re: Function "name" property

I send a new topic message about the following, but for some reason it seems slow getting to es-discuss. So, I'm trying it via a replay: Here is a new proposal for some additional meta properties that should be considered for ES7 https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md

Proposal: Additional Meta Properties for ES7

Here is a new proposal for some additional meta properties that should be considered for ES7 https://github.com/allenwb/ESideas/blob/master/ES7MetaProps.md I've added this to the agenda for next months TC39 meeting but pre-meeting discussion is always welcomed right here. Allen __

Re: Proposal: Additional Meta Properties for ES7

Once you are willing to move beyond "callee", there are a whole lot of available English words: function.me function.here function.this (I kinda like it but I also don't believe it would be a good choice) function.target function.self (suggested by Claude) function.object (you are accessing

Re: Proposal: Additional Meta Properties for ES7

((n)=>n>1? n*function.callee(n-1) : 1) On Feb 26, 2015, at 4:42 PM, Garrett Smith wrote: > Can you show an example of how callee is used with a fat arrow function? > > (()=>{alert(callee);})() > > Thanks. > > On 2/26/15, Allen Wirfs-Brock wrote: >

Re: Function "name" property

On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote: > > But > function.next -- Current yield result > > is awesome! Bravo. It solves a problem which is otherwise really hard to > express. > Actually, another possible name for this that I want to put on the table is: function.last --- the la

Re: Function "name" property

On Feb 26, 2015, at 3:55 PM, Mark S. Miller wrote: > For most of these, my first reaction is meh. They all make sense and violate > no principle, but are they worth it? > > I do not like the arrow function behavior. For anything named > function.something occurring within an arrow function, I'd

Re: Proposal: Additional Meta Properties for ES7

On Feb 27, 2015, at 12:27 AM, Leon Arnott wrote: > I feel a little unhappy that one meta-property, `new.target`, is lexically > scoped in arrow functions but these new ones aren't, without much obviously > distinguishing them. I guess you could concoct the reasoning that since > arrows can't b

Re: Proposal: Additional Meta Properties for ES7

On Feb 27, 2015, at 7:59 AM, Claus Reinke wrote: > > For concise methods, the problem is already solved by 'this', > isn't it? > > ({f(n){return n>1?n*this.f(n-1):1}}.f)(6) > 720 No, not for the general case. You could have arrived here via a 'super' method call in which case 'this.f' wil

Re: Function "name" property

On Feb 27, 2015, at 8:00 AM, Rick Waldron wrote: > > I was thinking exactly this while I was reading Allen's post. > > Would class method definitions use `class.*`? Seems like the wrong > abstraction..? Maybe all functions and method definitions use `function`, > while arrows use `=>` (or what

Re: Function "name" property

On Feb 28, 2015, at 9:07 AM, Brendan Eich wrote: > > No, again, I'm objecting to Allen's just-so story that `function` in an arrow > refers to the arrow, and agreeing with Mark that the pellucid meaning (if > there is one) would be the TCP one: the enclosing function around the arrow > (if the

Re: Function "name" property

On Mar 2, 2015, at 9:22 AM, Rick Waldron wrote: > > > On Sun, Mar 1, 2015 at 4:17 AM Leon Arnott wrote: > On Sun, Mar 1, 2015 at 3:28 AM, Allen Wirfs-Brock > wrote: > If you want both a TCP-able from and a local (most closely enclosing callable > thing) form then

Re: Proposal: Additional Meta Properties for ES7

On Mar 2, 2015, at 9:30 AM, John Lenz wrote: > I was recently discussion Promise optimizations (specifically, that in any > "then" chain at least one Promise object is created that goes unused), this > could be solved by some metadata that indicated whether the result of the > function would b

Re: Why GeneratorFunction constructor isn't directly exposed to end users?

On Feb 28, 2015, at 2:20 PM, Michał Wadas wrote: > It could be either Function property or new global object... Or an import from a standard module. It wasn't directly exposed in ES6 was because it lacked strong use cases and we didn't want to clutter up the global namespace with something of

Re: Class double-bind

see belolw On Mar 2, 2015, at 1:35 PM, Erik Arvidsson wrote: > Classes are more similar to function expressions which do have an internal > const binding. > > One way to desugar ClassDeclaration is to desugar it into a let binding for a > ClassExpression. [1] > > let Foo = class Foo extends e

Re: Class double-bind

On Mar 2, 2015, at 3:14 PM, Jason Orendorff wrote: > On Mon, Mar 2, 2015 at 4:15 PM, Allen Wirfs-Brock > wrote: >> and conversely if we have something like this: >> >> class Bar { >> constructor(n) {this.n=n} >> static get const() {return 42); &

Re: Class double-bind

On Mar 4, 2015, at 4:21 AM, Jason Orendorff wrote: > Oops, accidentally sent this only to Allen. > and I replied as follows: On Mar 3, 2015, at 9:34 AM, Jason Orendorff wrote: > On Mon, Mar 2, 2015 at 5:54 PM, Allen Wirfs-Brock > wrote: >> Pretty much everyone I&#x

Re: How to fix the `class` keyword

On Mar 4, 2015, at 1:50 PM, Matthew Robb wrote: > > On Wed, Mar 4, 2015 at 2:29 PM, Kevin Smith wrote: > In order to allow subclassing as built-ins, we had to opt for the builtin > model. > > ​Help me make sure I am understanding correctly. This decision doe​s not help > in making DOM subcla

ES6 Release Candidate 2

ES6 Release Candidate 2 is now available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#march_4_2015_rev_35_release_candidate_2 Changes marked as “Rev 35“. Change markup is cumulative starting with Release Candidate 1 (Rev34). Changes include: Reverted back to no legac

Re: Class double-bind

mpion this through that process? Allen > > On Thu, Mar 5, 2015 at 9:51 AM Andreas Rossberg wrote: > On 5 March 2015 at 04:57, Brendan Eich wrote: > Allen Wirfs-Brock wrote: > This is novel weirdness. > > In C++/Java/C# etc. you don't see it because the corresponding

Re: Class double-bind

On Mar 5, 2015, at 8:50 AM, Domenic Denicola wrote: > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris > Zbarsky > >> Just to be clear, this would make class declarations behave differently from >> builtins, both the ES kind and the IDL kind, right? > > I think that

Re: Understanding static semantics

On Mar 6, 2015, at 3:46 AM, raul mihaila wrote: > Do sentences like "it's a syntax error if the LexicallyDeclaredNames of > StatementList contains any duplicate entries" (section 15.1.1) refer to the > result of applying the LexicallyDeclaredNames rule for a production > alternative in which S

Re: Object arithmetic--operator alternative to Object.assign

On Mar 11, 2015, at 7:23 AM, Bergi wrote: > Bob Myers schrieb: >> Apologies if something like this has already been proposed and/or rejected >> for whatever reason. > > I think you're looking for the same as > http://wiki.ecmascript.org/doku.php?id=strawman:define_properties_operator also see:

Re: unresolved 6th edition bugs

On Mar 11, 2015, at 12:31 PM, Michael Dyck wrote: > What happens to all the unresolved 6th edition bugs when 6th edition is > finalized? (There's currently about 66 in the "Confirmed" state.) Do they > all get transferred over to 7th edition? Or do they stay where they are, > hoping for resolutio

Re: Comma operator in Arrow functions

On Mar 14, 2015, at 12:37 PM, Caitlin Potter wrote: > ConciseBody is an AssignmentExpression in this case, so I believe the comma > is a syntax error. no, comma is the lowest precedence of any operator. hence: a=1,2 parses as: (a=1),2 and a=()=>1,2 parses as: (a=()=>1),2 Finally, note

Re: Comma operator in Arrow functions

On Mar 14, 2015, at 1:00 PM, Caitlin Potter wrote: >> no, comma is the lowest precedence of any operator. > > I think you might have misunderstood what I was saying? > > ConciseBody -> AssignmentExpression -> comma is not a part of the ConciseBody > -> you probably get a SyntaxError unless the

Re: Comma operator in Arrow functions

On Mar 14, 2015 6:53 PM, Leon Arnott wrote: > > On Sun, Mar 15, 2015 at 5:52 AM, Allen Wirfs-Brock wrote: >> >> >> >> Finally, note that >> >> console.log(a=1,2) >> >> assigns the value 1 to a, but outputs 2 >> > &

Re: Module import/export bindings

On Mar 15, 2015, at 9:43 PM, Domenic Denicola wrote: > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Kyle > Simpson > >> Would it then be appropriate to explain that conceptually the binding would >> otherwise indeed be 2-way, but that the immutable/read-only nature of

Re: Module import/export bindings

On Mar 16, 2015, at 9:26 AM, Mark Miller wrote: > Story is way too simple. JS const means constant, unchanging. By contrast, > import bindings, like const in C++, means "read-only view". This is *very* > different from constant. > > Don't use the "const" analogy when changes are still observab

Re: Reflect.getOwnPropertySymbols?

On Mar 15, 2015, at 2:48 PM, Keith Cirkel wrote: > It seems like the intention of the Reflect API was to create a standard > object were all reflection operations could reside. > > Now that we have modules, a “@reflect” module is a more natural place for > many of the reflection methods previo

Re: What is the difference between `newTarget` and `F` in abstract operation `Construct(..)` ?

On Mar 16, 2015, at 10:32 AM, Coolwust wrote: > From ES 6, section 7.3.14, there is an abstract operation `Construct (F, > [argumentsList], [newTarget])`, so if I have the following code `var foo = > new bar()`, then `newTarget` is the same as `F`, which is `bar`. > > My question is, in what

New ES6 draft - Release Candidate 3, Rev36

Is available at: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#march_17_2015_rev_36_release_candidate_3 Changes include: Several significant fixes relating to “completion reform” Various formatting tweaks and minor editorial and technical bug fixes. Resolved bugs: 4167-4

Re: Module import/export bindings

On Mar 18, 2015, at 9:34 AM, caridy wrote: > Kyle, same answer, `let x = y` is just an assignment. btw, you cannot change > `y` in that module, that's a static error. Assignment to 'y' a dynamic error. A while ago we eliminated all early errors that required static determination that their t

Re: Expression Closures as Compliment to Arrow Functions

> On Mar 23, 2015, at 10:42 AM, Jacob Parker > wrote: > > I noticed expression closures, as defined below, have been excluded from the > spec. > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Expression_closures > >

Re: 'var' legal in for..in?

> On Mar 23, 2015, at 2:45 PM, Mark Ethan Trostler > wrote: > >> Howdy, >> Is this legal ES6 syntax: >> >> for (var x in [ 1,2,3 ] ) { ... } //? >> >> Can the 'var' be in there? There was alleged talk at some point about >> making that illegal? Hard to tell from looking

Re: Supporting feature tests directly

> On Mar 22, 2015, at 2:00 AM, Kyle Simpson wrote: > >> I think you're referring to the `eval` function? > > Actually, I'm referring to proposing something new that would substitute for > having to hack feature tests with `eval`. > > These are the initial details of my idea, a `Reflect.suppor

Re: Forwarding `return()` in generators

> On Mar 26, 2015, at 10:50 PM, Axel Rauschmayer wrote: > > `return()` being optional is true for arrays: > > ... > > But it is not true for generators: but it is... > > ```js > function* elements() { > yield 'a'; > yield 'b'; > yield 'c'; > } ```js elements.prototype.return

Re: Determine if a value is Callable/Constructible

> On Mar 29, 2015, at 11:51 PM, Caitlin Potter wrote: > > ... > > Reflect.isConstructor(fn) -> true if Class constructor, generator, or legacy > (and non-builtin) function syntactic form > Reflect.isCallable(fn) -> true for pretty much any function, except for class > constructors and a few b

Re: Determine if a value is Callable/Constructible

> On Mar 30, 2015, at 8:09 AM, Yehuda Katz wrote: > > ... > > I don't think this is an accurate representation of the discussion we had. It’s my characterization of the situation and reflects my position. I agreed to disabling calling class constructors via a throw in order to get the consens

Re: Determine if a value is Callable/Constructible

> On Mar 30, 2015, at 8:40 AM, Axel Rauschmayer wrote: > > It doesn’t seem that big of a deal, but one risk is: people mistaking a class > for a constructor, trying to subclass it as if it were a constructor and > things failing silently. > Can you give an example of what you mean? Allen ___

Re: Determine if a value is Callable/Constructible

> On Mar 30, 2015, at 10:12 AM, Axel Rauschmayer wrote: > >>> It doesn’t seem that big of a deal, but one risk is: people mistaking a >>> class for a constructor, trying to subclass it as if it were a constructor >>> and things failing silently. >>> >> Can you give an example of what you mean

Re: last value from iterator

On Apr 5, 2015, at 6:04 AM, Mark Volkmann wrote: > I thought that when an iterator returns done: true, the value should not be > used. Why do you think that? The definition of the IteratorResult interface in the the ES6 spec. doesn't say that. > However, if a generator function ends by retur

Re: loop unrolling and completion values in ES6

Alan, I freed up goa couple minutes for a quick look at this. I want to spend some more time look at it deeper as this is an area where I made some fixes just a couple weeks ago and I want to review them again to make sure everything is as intended. But, for now a quick answer to your questi

Re: The ES6 iteration protocol

> On Apr 6, 2015, at 2:23 PM, Dmitry Soshnikov > wrote: > > I guess all built-in iterators return themselves for `Symbol.iterator` > protocol. So they are all "singletons". I described in detail where > confusion/substitution of concepts happens in that analysis in the recent two > comments.

Re: loop unrolling and completion values in ES6

> On Apr 7, 2015, at 10:09 AM, Alan Schmitt > wrote: > > Hi Allen, > > On 2015-04-06 02:08, Allen Wirfs-Brock writes: > >> Alan, >> >> I freed up a couple minutes for a quick look at this. I want to spend some >> more time look at it deeper as

Re: the Great Tooling Revolution

> On Apr 8, 2015, at 12:19 PM, Domenic Denicola wrote: > > This was discussed briefly at the previous meeting, perhaps un-minuted. > > The basic plan is to develop the spec on GitHub, using [Ecmarkup][] and > [Ecmarkdown][]. It will take pull requests, have a master branch that you can > view

Re: loop unrolling and completion values in ES6

> On Apr 9, 2015, at 10:44 AM, Alan Schmitt > wrote: > > 1. Let sl be the result of evaluating StatementList. > 2. ReturnIfAbrupt(sl). > 3. Let s be the result of evaluating StatementListItem. > 4. If s.[[type]] is throw, return Completion(s). > 5. If s.[[value]] is empty, let V = sl.[[value]],

Re: Well-Known Symbols: Array item getter/setter

> On Apr 9, 2015, at 2:37 PM, Jordan Harband wrote: > > One advantage of this approach is that more "spec magic" can be implemented > in terms of the language - it would also make subclassed arrays more > versatile instead of having to always be a Proxy. see http://wiki.ecmascript.org/doku.ph

Re: super() on class that extends

> On Apr 10, 2015, at 8:06 PM, Axel Rauschmayer wrote: > > ... > If you do not call `super()`, you only get into trouble if you access `this` > in some manner. Two examples: > > ... > > Therefore, there are two ways to avoid typing super-constructor calls. > > First, you can avoid accessing

Re: super() on class that extends

> On Apr 10, 2015, at 10:29 PM, Axel Rauschmayer wrote: > > No engine has implemented subclassing of `Array`, yet: > http://kangax.github.io/compat-table/es6/#Array_is_subclassable > > > And, as Sebastian mentioned, you can’t t

Re: super() on class that extends

> On Apr 10, 2015, at 10:54 PM, Allen Wirfs-Brock wrote: >> > > note totally true: err, “not" > > ```js > class SubArray extends Array { >constructor(…args) { > let newObj = new Array(…args); > newObj.__proto__ = SubArray.prototype; //

Re: Number.prototype not being an instance breaks the web, too

On Apr 13, 2015, at 8:26 AM, Mark S. Miller wrote: > ... > > Allen, process-wise, is this too late for ES6? If there's any way this fix > can go in ES6, it should. Otherwise, it should become the first member of ES6 > errata. yes, no I have to submit the final version for distribution to the

Final ES6 Draft

The final ES6 ECMAScript 2014 specification draft has been completed and submitted to the Ecma GA for their consideration and review prior to their June vote to approve it as a standard. The final draft is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#final_dr

Re: Should "const" be favored over "let"?

On Apr 17, 2015, at 5:09 AM, Alex Kocharin wrote: > > There won't be any performance gain. "const" is used to be much slower in v8 > actually. But they fixed it as far as I know. > > I think it's a code style matter. And speaking about that, realistically, > most code base will never use "c

Re: Please volunteer to maintain the HTML version of the spec

On Apr 17, 2015, at 6:20 AM, Jason Orendorff wrote: > On Thu, Apr 16, 2015 at 3:35 PM, Michael Dyck wrote: >> I'm interested. > > OK, thanks. I'll get back to you next week. Unfortunately I'm not around > today. We should probably start by forking your repository and hosting it on https://gi

Re: String.prototype.search has a breaking change from ES5

On Apr 18, 2015, at 12:46 PM, Yusuke SUZUKI wrote: > Hi forks, > > Seeing ES6 String.prototype.search, there's a breaking change from ES5. > > When executing `"gnulluna".search(null)`, > > In ES5, RegExp(null) => /null/ is generated, so the result becomes 1. > > http://ecma-international.org/

Re: stack-unlike behaviour of the execution context stack

On Apr 20, 2015, at 8:55 AM, a.d.be...@web.de wrote: > Hello! > In > , > a paragraph reads: > > | Transition of the running execution context status among execution > | contexts usually occurs in stack-like last-in/fi

Re: super.prop assignment can silently overwrite non-writable properties

On Apr 20, 2015, at 9:38 AM, Jason Orendorff wrote: > We're implementing `super` in Firefox, and ran across this surprising > behavior: > >class X { >constructor() { >Object.defineProperty(this, "prop", { >configurable: true, >writable: fa

Re: super.prop assignment can silently overwrite non-writable properties

On Apr 20, 2015, at 11:11 AM, Rick Waldron wrote: > > > On Mon, Apr 20, 2015 at 1:45 PM Allen Wirfs-Brock > wrote: > > On Apr 20, 2015, at 9:38 AM, Jason Orendorff wrote: > > > We're implementing `super` in Firefox, and ran across this surprising

Re: super.prop assignment can silently overwrite non-writable properties

On Apr 20, 2015 12:42 PM, Caitlin Potter wrote: > > Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the > example case, because the old descriptor is configurable. That’s kind of weird Hmm...I'm not at my machine right now. When I am I'll to make sure thus isn't a regressio

Re: super.prop assignment can silently overwrite non-writable properties

On Apr 20, 2015, at 12:42 PM, Caitlin Potter wrote: > Oh — he’s right, ValidateAndApplyPropertyDescriptor won’t throw in the > example case, because the old descriptor is configurable. That’s kind of > weird. It is kind of weird, but that was what TC39 decided on back when ES5 was being devel

Re: super.prop assignment can silently overwrite non-writable properties

the accessor property into a data property, which seems even more bogus then the ignore writable behavior. Allen > >> On Apr 20, 2015, at 8:17 PM, Allen Wirfs-Brock wrote: >> >> >>> On Apr 20, 2015, at 12:42 PM, Caitlin Potter wrote: >>> >>&

Re: super.prop assignment can silently overwrite non-writable properties

On Apr 20, 2015, at 12:39 PM, Jason Orendorff wrote: > On Mon, Apr 20, 2015 at 12:44 PM, Allen Wirfs-Brock > wrote: >>> In the spec, 9.1.9 step 4.d.i. is where `super.prop = 2` ends up, with >>> O=X.prototype. >> >> 4.d.1 doesn't set the pro

Re: super.prop assignment can silently overwrite non-writable properties

hat happens when we do [[HomeObject]].[[GetPrototypeOf]]().[[Set]]('prop', x, this) Allen > > On Tue, Apr 21, 2015 at 4:18 AM, Allen Wirfs-Brock > wrote: > > On Apr 20, 2015, at 12:39 PM, Jason Orendorff wrote: > >> On Mon, Apr 20, 2015 at 12:44

Re: super.prop assignment can silently overwrite non-writable properties

On Apr 20, 2015, at 11:55 AM, Rick Waldron wrote: > > > On Mon, Apr 20, 2015 at 2:31 PM Allen Wirfs-Brock > wrote: > On Apr 20, 2015, at 11:11 AM, Rick Waldron wrote: > >> >> > >> - It is a Syntax Error if ClassHeritage is not present and >

Re: super.prop assignment can silently overwrite non-writable properties

falls throw steps 4 and 5 and eventually invokes its setter in step 9. The Receiver (the original `this` value only is involved as the `this` value passed in the call to the setter. Allen > >> On Apr 20, 2015, at 9:37 PM, Allen Wirfs-Brock wrote: >> >> >>

Re: super.prop assignment can silently overwrite non-writable properties

On Apr 21, 2015, at 12:31 PM, Tom Van Cutsem wrote: > FWIW, you can reproduce this test case without reference to the new `super` > syntax: > > ``` > var parent = {}; > var x = Object.create(parent, { > prop: { value: 1, configurable: true, writable: false } > }); > > Reflect.set(parent, "pr

Re: Are ES6 modules in browsers going to get loaded level-by-level?

On Apr 23, 2015, at 10:35 PM, James Burke wrote: > On Thu, Apr 23, 2015 at 4:48 PM, Brendan Eich wrote: > Your lament poses a question that answers itself: in time, ES6 will be > the base level, not ES3 or ES5. Then, the loader can be nativized. > Complaining about this now seems churlish. :-| >

Re: is an iterator allowed to reuse the same "state" object?

On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote: > On Mon, Apr 27, 2015 at 3:11 PM, John Lenz wrote: >> By which I mean the object that returns the current value and "done" state? > > IIRC, it's not supposed to. The built-in iterators will return fresh > objects each time, so there's no muta

Re: Subclassing ES6 objects with ES5 syntax.

On Apr 27, 2015, at 8:01 PM, Kevin Smith wrote: > x = Reflect.construct(Promise, x, C); > > is another fine way to fool someone who wrote "C.resolve(x)" and expected to > get an instance of C back. > > Thanks for pointing this out. I believe the ability to use an arbitrary > newTarget parame

Re: Subclassing ES6 objects with ES5 syntax.

On Apr 28, 2015, at 1:08 PM, Kevin Smith wrote: > > What is the use case for third argument to Reflect.construct? The primary use case is emulating the super() call semantics in a Proxy construct trap handler. Allen ___ es-discuss mailing list es-d

Re: is an iterator allowed to reuse the same "state" object?

on at all. Allen > On Apr 27, 2015 4:59 PM, "Allen Wirfs-Brock" wrote: > > On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote: > >> On Mon, Apr 27, 2015 at 3:11 PM, John Lenz wrote: >>> By which I mean the object that returns the current value and &quo

Re: Subclassing ES6 objects with ES5 syntax.

On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich wrote: > Kevin Smith wrote: > So what would the ideal Promise.resolve semantics do? I'm not sure, maybe > use SpeciesConstructor instead of [[PromiseConstructor]]? > > This removes the wart in

Re: Additional Math functions

On Apr 29, 2015, at 9:04 AM, C. Scott Ananian wrote: > ... > I suppose it would be nice if JavaScript engines fell back to passing > arguments on the heap to avoid this problem, but I don't think that's part of > the ES6 spec. Am I mistaken? that's an implementation detail. The ES spec. doesn

==

On Apr 29, 2015, at 11:12 AM, C. Scott Ananian wrote: > > Since it's `Promise.then` you care about, I think the approach in my previous > message (where `then` is tested directly) is preferable. I agree. If what you specifically care about is the `then` behavior you should be checking for a k

Re: Subclassing ES6 objects with ES5 syntax.

On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock > wrote: > class DefensivePromise extends Promise { > constructor(x) { > super(x); > if (new.target === DefensivePromise) { >// I'm assumi

Re: Subclassing ES6 objects with ES5 syntax.

On Apr 29, 2015, at 12:40 PM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock > wrote: > On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote: >> On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock >> wrote: >> class Defen

Re: Subclassing ES6 objects with ES5 syntax.

On Apr 29, 2015, at 2:44 PM, Mark S. Miller wrote: > On Wed, Apr 29, 2015 at 2:36 PM, C. Scott Ananian > wrote: > [...] > Mark, after you've slept on this and assuming you haven't changed your mind, > would you be willing to be the TC39 champion? I'm not a participant in that > process. > >

Re: Subclassing ES6 objects with ES5 syntax.

On Apr 29, 2015, at 2:36 PM, C. Scott Ananian wrote: > On Wed, Apr 29, 2015 at 4:16 PM, Allen Wirfs-Brock > wrote: > On Apr 29, 2015, at 12:40 PM, C. Scott Ananian wrote: >> On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock >> wrote: >> On Apr 29, 2015, at 12:24

  1   2   3   4   5   6   7   8   9   10   >