Re: Can `let`, `static` and `yield` still be used as Identifier?
Gary is right: `let` is disabled for web content in Firefox because our version isn't spec-compatible enough yet. In the shell or chrome code, where it is enabled, our behavior matches traceur's in that we treat the given examples as errors, too. On Fri, Jan 2, 2015 at 4:40 PM, Gary Guo nbdd0...@hotmail.com wrote: Thanks for your note, I'm not testing it under Nightly. Did you test that the 'let' declaration is working properly in JSFiddle? It may not be enabled in web pages by default if the script doesn't declare to be javascript 1.7. -- From: waldron.r...@gmail.com Date: Fri, 2 Jan 2015 14:23:31 + Subject: Re: Can `let`, `static` and `yield` still be used as Identifier? To: nbdd0...@hotmail.com CC: es-discuss@mozilla.org On Thu Jan 01 2015 at 9:47:47 PM Gary Guo nbdd0...@hotmail.com wrote: It seems that in JSFiddle running on Firefox, let declaration is disabled. So this cannot explain. I don't know why you'd say that, considering the fiddle works just fine. Open your developer console and you'll see the output. Note that I'm referring to Nightly. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Can `let`, `static` and `yield` still be used as Identifier?
Thanks for your note, I'm not testing it under Nightly. Did you test that the 'let' declaration is working properly in JSFiddle? It may not be enabled in web pages by default if the script doesn't declare to be javascript 1.7. From: waldron.r...@gmail.com Date: Fri, 2 Jan 2015 14:23:31 + Subject: Re: Can `let`, `static` and `yield` still be used as Identifier? To: nbdd0...@hotmail.com CC: es-discuss@mozilla.org On Thu Jan 01 2015 at 9:47:47 PM Gary Guo nbdd0...@hotmail.com wrote: It seems that in JSFiddle running on Firefox, let declaration is disabled. So this cannot explain. I don't know why you'd say that, considering the fiddle works just fine. Open your developer console and you'll see the output. Note that I'm referring to Nightly. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Can `let`, `static` and `yield` still be used as Identifier?
On Thu Jan 01 2015 at 9:47:47 PM Gary Guo nbdd0...@hotmail.com wrote: It seems that in JSFiddle running on Firefox, let declaration is disabled. So this cannot explain. I don't know why you'd say that, considering the fiddle works just fine. Open your developer console and you'll see the output. Note that I'm referring to Nightly. Rick -- From: waldron.r...@gmail.com Date: Wed, 31 Dec 2014 21:36:46 + Subject: Re: Can `let`, `static` and `yield` still be used as Identifier? To: a...@kocharin.ru; erik.arvids...@gmail.com; nbdd0...@hotmail.com; es-discuss@mozilla.org let = 1; console.log(let); // 1 var let = 1; console.log(let); // 1 let let = 1; // SyntaxError ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why does Symbol.for and Symbol.keyFor are limited to strings?
On Jan 2, 2015, at 9:18 AM, Michał Wadas wrote: What is reason behind restricting entries in global symbol registry to be indexed only by strings? What are the use cases for anything other strings? Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Why does Symbol.for and Symbol.keyFor are limited to strings?
What is reason behind restricting entries in global symbol registry to be indexed only by strings? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Octal escape sequences in string and regexp literals
I think there are a few reasons why you wouldn't want these. First and foremost, octal escapes (\nnn) are just an alternative equivalent to hex escapes (\xnn). Most software developers spend a lot more time dealing with hex when it comes to byte values, and very little time with octal literals outside of things like unix file permissions. The most useful octal literal would be \0, and this is already explicitly permitted in strict mode. So, I don't think there's any real compelling use case for the alternative representation of byte values. So to summarize, supporting these in strict mode would be adding another way to accomplish the same given task (which grows the language for no real reason and with no benefit), does not make string literals easier to read and understand, and does not enable software developers to perform any compelling task which was not more easily accomplished using hex literals. Finally, the most common use-case for this feature is already supported in strict mode. More important, octal escape sequences are a bit liberal, in that they can be of several lengths, with a pretty wide range of delimiters. This, I think, results in many cases where octal escape sequences are used by accident, rather than intentionally. It's a footgun, and ideally that footgun should not be there. I feel like the refactoring pain argument is not very compelling, because I am not convinced beginners are likely to use octal literals on purpose (or even by accident). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
One reason it might make sense to throw, is people converting values to string names for use as object properties. Reason you'd want to throw would be to prevent accidentally making the key useless (different from its original Symbol value). Haven't paid attention to the rationale, but that doesn't seem like a bad one. On Jan 2, 2015, at 6:26 PM, Rick Waldron waldron.r...@gmail.com wrote: Kyle Simpson brought this up on Twitter today and I think it deserves one last look. Here's an example of the issue: var sym = Symbol(description); sym + ; // Throws Meanwhile... var sym = Symbol(description); String(sym); // Symbol(description) * (* appears to be the convention that implementors have converged on) This is the only time that a thing in JavaScript throws when it encounters an implicit coercion operation. This detail appears to be problematic in that it's an unnecessary divergence from the language's normal behaviour. Ref: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-addition-operator-plus-runtime-semantics-evaluation 11.a Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
On Fri Jan 02 2015 at 7:53:22 PM Brendan Eich bren...@mozilla.org wrote:
Caitlin Potter wrote:
One reason it might make sense to throw, is people converting values
to string names for use as object properties. Reason you'd want to
throw would be to prevent accidentally making the key useless
(different from its original Symbol value).
This is exactly the reason.
Yep, I just wanted to make sure the subject got some last minute airtime to
make sure this is _really_ the way to go. I'll play the opposition here: is
the hazard as compelling now as it was when it was first discussed? Now
that implementors have had some time to work with Symbol, do proponents of
throw still feel strongly?
Of course, having String(x) and '' + x diverge is funky, but not novel:
Sure, but the argument was re: the implicit coercion of built-ins.
Rick
js o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function valueOf(){return 42}, toString:function
toString(){return 'haha'}})
js String(o)
haha
js ''+o
42
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Octal escape sequences in string and regexp literals
Hi, Current web browsers implement octal escape sequences of the form \52, representing the character of code 0o52, in string literals in sloppy mode only, and in regexps (at the condition there is less than 52 capturing groups) in both sloppy and strict mode. (In order to avoid confusion: I am *not* concerned with legacy octal integer literals of the form: 052, representing the number 0o52.) As far as I can infer from archives of es-discuss, these escape sequences was an undesired feature that was not standardised (in ES3), but that everyone implemented and was needed for web compatibility. So, it was decided to exclude it from ES5 strict mode, and therefore from Harmony which was thought to be built on strict mode, for 1JS wasn't invented back then. Now, times have changed, and, in the sake of 1JS, new features are implemented in both sloppy and strict mode; or otherwise said, the difference between the two modes is kept as small as possible. From that new perspective, is there still a strong enough reason to exclude these escape sequences from string literals in strict mode, that would justify the discrepency between strict and sloppy modes? And if so, what to do with regexps? —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal escape sequences in string and regexp literals
Le 2 janv. 2015 à 22:08, Caitlin Potter caitpotte...@gmail.com a écrit : (...) More important, octal escape sequences are a bit liberal, in that they can be of several lengths, with a pretty wide range of delimiters. This, I think, results in many cases where octal escape sequences are used by accident, rather than intentionally. It's a footgun, and ideally that footgun should not be there. Concretely, the danger is that someone could write \07 when they mean \0 + 7. This is a good point. (Were you thinking of other cases when you wrote many cases?) I feel like the refactoring pain argument is not very compelling, because I am not convinced beginners are likely to use octal literals on purpose (or even by accident). I agree on that point, and therefore I didn't make any refactoring argument. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
One reason it might make sense to throw, is people converting values to
string names for use as object properties. Reason you'd want to throw would
be to prevent accidentally making the key useless (different from its
original Symbol value).
This is exactly the reason.
Of course, having String(x) and '' + x diverge is funky, but not novel:
js o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function valueOf(){return 42}, toString:function toString(){return
'haha'}})
js String(o)
haha
js ''+o
42
Playing devil’s advocate: How realistic a danger is this? Do people ever
compose a property key for an object out of several pieces?
It does add a fair amount of complexity for something that doesn’t seem that
common.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Implicit coercion of Symbols
Kyle Simpson brought this up on Twitter today and I think it deserves one last look. Here's an example of the issue: var sym = Symbol(description); sym + ; // Throws Meanwhile... var sym = Symbol(description); String(sym); // Symbol(description) * (* appears to be the convention that implementors have converged on) This is the only time that a thing in JavaScript throws when it encounters an implicit coercion operation. This detail appears to be problematic in that it's an unnecessary divergence from the language's normal behaviour. Ref: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-addition-operator-plus-runtime-semantics-evaluation 11.a Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
Caitlin Potter wrote:
One reason it might make sense to throw, is people converting values
to string names for use as object properties. Reason you'd want to
throw would be to prevent accidentally making the key useless
(different from its original Symbol value).
This is exactly the reason.
Of course, having String(x) and '' + x diverge is funky, but not novel:
js o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function valueOf(){return 42}, toString:function
toString(){return 'haha'}})
js String(o)
haha
js ''+o
42
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
On 1/2/15 9:33 PM, Axel Rauschmayer wrote: Do people ever compose a property key for an object out of several pieces? On the web? All the time. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
On 1/2/15 9:40 PM, Axel Rauschmayer wrote:
Can you give an example?
get: function( num ) {
return num != null ?
// Return just the one element from the set
( num 0 ? this[ num + this.length ] : this[ num ] ) :
// Return all the elements in a clean array
slice.call( this );
},
That's from jQuery 2.1.3.
And from the same place:
function cache( key, value ) {
// Use (key + ) to avoid collision with native prototype properties
(see Issue #157)
if ( keys.push( key + ) Expr.cacheLength ) {
// Only keep the most recent entries
delete cache[ keys.shift() ];
}
return (cache[ key + ] = value);
}
That's after looking through about 1/10 of the library. I'll bet there
are more. I'll also bet this sort of thing appears in every single
major library out there.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Why does Symbol.for and Symbol.keyFor are limited to strings?
Why not? Symbol's [[Description]] internal slot is string Date: Fri, 2 Jan 2015 18:18:55 +0100 Subject: Why does Symbol.for and Symbol.keyFor are limited to strings? From: michalwa...@gmail.com To: es-discuss@mozilla.org What is reason behind restricting entries in global symbol registry to be indexed only by strings? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
Can you give an example? On 03 Jan 2015, at 03:34, Boris Zbarsky bzbar...@mit.edu wrote: On 1/2/15 9:33 PM, Axel Rauschmayer wrote: Do people ever compose a property key for an object out of several pieces? On the web? All the time. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
