Re: Re: is PropertyName updated?

Oops, sorry, I've missed PropertyName : *BindingElement*. So when using computed property name as PropertyName, shorthanded style cannot be used. Thank you ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

is PropertyName updated?

Hi forks. Seeing the latest rev 27 draft, PropertyName is defined in the 12.2.5, PropertyName[Yield,GeneratorParameter] : LiteralPropertyName [+GeneratorParameter] ComputedPropertyName [~GeneratorParameter] ComputedPropertyName[?Yield] And BindingProperty in the ObjectBindingPattern

Re: Questions regarding ES6 Unicode regular expressions

On Aug 26, 2014, at 1:45 PM, Norbert Lindenberg wrote: > > On Aug 26, 2014, at 11:15 , Mathias Bynens wrote: > >> On 26 Aug 2014, at 19:01, Allen Wirfs-Brock wrote: > >>> I see one remaining issue: >>> In ES5 (and ES6): `/a-z/i` does not match U+017F (ſ) or U+212A (K) because >>> the ES ca

Re: Questions regarding ES6 Unicode regular expressions

On Aug 26, 2014, at 11:15 , Mathias Bynens wrote: > On 26 Aug 2014, at 19:01, Allen Wirfs-Brock wrote: >> I see one remaining issue: >> In ES5 (and ES6): `/a-z/i` does not match U+017F (ſ) or U+212A (K) because >> the ES canonicalization algorithm excludes mapping code points > 127 that >>

Re: Questions regarding ES6 Unicode regular expressions

Le 26 août 2014 à 20:15, Mathias Bynens a écrit : > On 26 Aug 2014, at 19:01, Allen Wirfs-Brock wrote: > >> I've thought about this a bit. I was initially inclined to agree with the >> idea of extending the existing character classes similar to what Mathias' >> proposes. But I now think tha

Re: Rev27 ES6 draft now available

This is now available in HTML at: http://people.mozilla.org/~jorendorff/es6-draft.html As always, please report any issues with the HTML version here: https://github.com/jorendorff/es-spec-html/issues and any issues with the document itself here: https://bugs.ecmascript.org/ -j On Mon, Aug

Re: Questions regarding ES6 Unicode regular expressions

On Aug 26, 2014, at 11:16 AM, Norbert Lindenberg wrote: > > On Aug 26, 2014, at 10:01 , Allen Wirfs-Brock wrote: > >> So, here is a summary of my proposal: > >> 3) Reserve within /u RegExp patterns, the syntax \p{} and >> \P{} > > This was already decided by TC39 at the March 2012 meeting,

Re: Questions regarding ES6 Unicode regular expressions

Le 26 août 2014 à 19:01, Allen Wirfs-Brock a écrit : > 3) Reserve within /u RegExp patterns, the syntax \p{} and > \P{} I'll go even further: when the `u` flag is on, it shall be verboten for implementations to interpret `\` followed by one of 0-9, A-Z or a-z as a literal character. (To be add

Re: Questions regarding ES6 Unicode regular expressions

On Aug 26, 2014, at 10:01 , Allen Wirfs-Brock wrote: > So, here is a summary of my proposal: > 3) Reserve within /u RegExp patterns, the syntax \p{} and > \P{} This was already decided by TC39 at the March 2012 meeting, and if I read the spec correctly, it’s already specified: IdentityEscap

Re: Questions regarding ES6 Unicode regular expressions

On 26 Aug 2014, at 19:01, Allen Wirfs-Brock wrote: > I've thought about this a bit. I was initially inclined to agree with the > idea of extending the existing character classes similar to what Mathias' > proposes. But I now think that is probably not a very good idea and that > what is curre

Re: Questions regarding ES6 Unicode regular expressions

I've thought about this a bit. I was initially inclined to agree with the idea of extending the existing character classes similar to what Mathias' proposes. But I now think that is probably not a very good idea and that what is currently spec'ed (essentially that the /u flag doesn't change the

Re: String(symbol)

Jeff Walden wrote: It's not the most correct way to do it. |a + ""| performs ToPrimitive(a, hint = None), whereas ToString(a) performed ToPrimitive(a, hint = String). The former consults valueOf, then toString, the latter the reverse. Argh, I had forgotten about the no-hint case there. It s

Re: String(symbol)

Brendan Eich wrote: Use +'' if you want ToString in the language, I say. asm.js points the way on other explicit conversion forms: ToString(x) is x+'' ToNumber(x) is +x ToInt32(x) is ~~x ToBoolean(x) is !!x /be ___ es-discuss mailing list es-discuss

Re: String(symbol)

Claude Pache wrote: >/ Personally, I use the following expression in order to coerce a variable to a string: />/ />/ var obj = this + '' />/ />/ and its in-place variant: />/ />/ x += '' />/ />/ I think it'll continue to work in ES6. / Agreed, this is the correct-and-most-con

Re: String(symbol)

On 08/26/2014 09:14 AM, Brendan Eich wrote: > Claude Pache wrote: >> Personally, I use the following expression in order to coerce a variable to >> a string: >> >> var obj = this + '' >> >> and its in-place variant: >> >> x += '' >> >> I think it'll continue to work in ES6. > > Agreed, th

RE: String(symbol)

`x+''` produces different results than ToString when `x = { toString() { return '5'; }, valueOf() { return 10; } }` From: es-discuss on behalf of Brendan Eich Sent: Tuesday, August 26, 2014 12:14 To: Claude Pache; Jeff Walden Cc: Erik Arvidsson; es-discu

Re: String(symbol)

Claude Pache wrote: Personally, I use the following expression in order to coerce a variable to a string: var obj = this + '' and its in-place variant: x += '' I think it'll continue to work in ES6. Agreed, this is the correct-and-most-concise way to do it. It should throw

Re: String(symbol)

Le 26 août 2014 à 17:39, Jeff Walden a écrit : > On 08/12/2014 11:07 PM, Allen Wirfs-Brock wrote: > > With this change, as far as I can tell there's no concise operation directly > corresponding to the ToString abstract operation. The best that seems > possible is some horribly indirect oper

Re: String(symbol)

On 08/26/2014 08:48 AM, Domenic Denicola wrote: > Why would it be useful, from a programmer's perspective, to expose ToString > directly? People will always want to polyfill, or prototype in advance of proposal for standardization. No matter how internal the operation might be, it's heavily us

RE: String(symbol)

Why would it be useful, from a programmer's perspective, to expose ToString directly? It is just a spec-internal thing, and the reason this change is made is because it is no longer very useful to directly expose that spec-internal thing given how it interacts with symbols. _

Re: String(symbol)

On 08/12/2014 11:07 PM, Allen Wirfs-Brock wrote: > sounds good to me, I'll update the spec. accordingly > > On Aug 12, 2014, at 7:39 PM, Erik Arvidsson wrote: >> I was suggesting that String(symbol) should not throw. >> >> This can be spec'ed as String( value ) checking the Type of the value and

Re: Fixing the associativity / precedence of the instanceof operator

I sort of like the `!` not operation as `!instanceof` in order to both `obj instanceof(Object)` and `obj !instanceof(Object)` but I find other ideas not so bad too, here a couple of examples: ```js // via Objects Object.defineProperty( Object.prototype, 'instanceOf', { enumerable: false,

Re: Fixing the associativity / precedence of the instanceof operator

 26.08.2014, 17:54, "Till Schneidereit" :On Tue, Aug 26, 2014 at 3:38 PM, Alex Kocharin wrote: > use developer tools such as linters. Those certainly should warn about code like that. I was trying to find such a tool a few days ago (after similar error was fixed in bunyan), and I

Re: Fixing the associativity / precedence of the instanceof operator

An `isnt` operator has been proposed before[1]. Parens are ugly. Proto[2] supports negating operators with `!` (`foo !in bar`, `foo !is bar`, `foo !like bar`). [1] http://wiki.ecmascript.org/doku.php?id=harmony:egal [2] https://github.com/Nathan-Wall/proto On Mon, Aug 25, 2014 at 6:40 AM, Ch

Re: Fixing the associativity / precedence of the instanceof operator

On Tue, Aug 26, 2014 at 3:38 PM, Alex Kocharin wrote: > > > use developer tools such as linters. Those certainly should warn about > code like that. > > I was trying to find such a tool a few days ago (after similar error was > fixed in bunyan), and I found nothing: > > https://gist.github.com/rl

Re: Fixing the associativity / precedence of the instanceof operator

 > use developer tools such as linters. Those certainly should warn about code like that. I was trying to find such a tool a few days ago (after similar error was fixed in bunyan), and I found nothing: https://gist.github.com/rlidwka/8b904ca00b1e76731270 So I agree that it should be catched by lint

Re: Strawman proposal: new `is` operator

I stand corrected on the creation aspect. Isiah Meadows On Aug 25, 2014 9:56 PM, "Brendan Eich" wrote: > Isiah Meadows wrote: > >> >> Cc the list... >> >> On Aug 25, 2014 6:06 PM, "Isiah Meadows" > impinb...@gmail.com>> wrote: >> >> There really shouldn't be any sort of object construction n

Re: Fixing the associativity / precedence of the instanceof operator

 You sound like strict mode is a different language designed to reduce user errors. It is not. It is just an intermediate mode between es3 and es7+, which makes incompatible changes easier, and the name is misleading. Making this an error in strict mode is only valid, if we are changing its precede

Re: Strawman proposal: new `is` operator

On Tue, Aug 26, 2014 at 3:56 AM, Brendan Eich wrote: > > ES4 had 'is' as a type-classifying operator: > > http://wiki.ecmascript.org/doku.php?id=proposals:is_as_to > http://wiki.ecmascript.org/doku.php?id=discussion:is_as_to > > It would be a mistake to define 'is' without defining the (unsound) t

Re: Fixing the associativity / precedence of the instanceof operator

On Tue, Aug 26, 2014 at 5:48 AM, Charles Pick wrote: > Ok, what if `!foo instanceof Foo` became a strict mode error instead? That'd increase the difference between the two modes, which is something nobody wants. Also, someone employing strict mode is also quite a bit more likely to use developer

Re: Fixing the associativity / precedence of the instanceof operator

I’m on the same page as Charles. I feel like it should be okay to fix something like this … at least in strict mode. Or introduce a tiny bit of new grammar supporting something like `foo ! instanceof Foo` (or `foo not instanceof Foo`) maybe? - Jonathan — Sent from Mailbox On Tue, Aug 26, 20

Re: Fixing the associativity / precedence of the instanceof operator

Ok, what if `!foo instanceof Foo` became a strict mode error instead? On Mon, Aug 25, 2014 at 12:08 PM, Till Schneidereit < t...@tillschneidereit.net> wrote: > On Mon, Aug 25, 2014 at 1:01 PM, Charles Pick wrote: > >> I agree that this could cause some problems, however, that code has never >>

Re: Proposal: generator#clone() and generator#goto()

Thank you. Seems like I could use a `switch` inside a `while (true)` loop to make transpiling easier but it's quite hacked and it don't allow you to skip to jump from a case to another unless carefully added guards. Don't you think goto() function is not safe enough? As I said, this is not for reg

Re: Questions regarding ES6 Unicode regular expressions

On 26 Aug 2014, at 02:16, Norbert Lindenberg wrote: > […] Thanks for confirming. Sounds like my “ES6 Unicode regular expressions to ES5” transpiler is working correctly, then: https://github.com/mathiasbynens/regexpu Demo: http://mothereff.in/regexpu (Bug reports welcome.) > On Aug 25, 2014,