Re: es-discuss Digest, Vol 95, Issue 14

[Isiah Meadows]

> From: Fred Schott 
> To: es-discuss@mozilla.org
> Cc:
> Date: Sun, 4 Jan 2015 23:06:56 -0600
> Subject: Question regarding duplicate computed __proto__ properties
> In Section B.3.1 on "__proto__ Property Names in Object Initializers" there 
> is a paragraph explaining when duplicate properties will result in a syntax 
> error. It says:
>
>> It is a Syntax Error if PropertyNameList of PropertyDefinitionList contains 
>> any duplicate entries for "__proto__" and at least two of those entries were 
>> obtained from productions of the form PropertyDefinition : PropertyName : 
>> AssignmentExpression .
>
>
> Where PropertyName is defined as:
>
>> PropertyName[Yield,GeneratorParameter] :
>>   LiteralPropertyName
>>   [+GeneratorParameter] ComputedPropertyName
>>   [~GeneratorParameter] ComputedPropertyName[?Yield]
>>
>> LiteralPropertyName :
>>   IdentifierName
>>   StringLiteral
>>   NumericLiteral
>
>
> That paragraph (using the definitions provided) seems to assert that it is a 
> syntax error if there are any duplicate uses of __proto__ with an 
> IdentifierName, StringLiteral, or ComputedPropertyName. To translate this 
> into an example, it seems to assert that in ES6 this is not valid:
>
>> var obj = {
>>   __proto__: somePrototype,
>>   ["__proto__"]: somePrototype
>> }
>>
>> // Error: SyntaxError
>
>
> Is that correct? Step 6 of Section B.3.1 explicitly states that the computed 
> ["__proto__"] does not have the same special behavior as the literal 
> property. But from my understanding of other es-discuss topics & resources, 
> the restriction on duplicate "__proto__" properties also does not apply to 
> computed properties. If that is true, then the quoted paragraph above seems 
> to be incorrect or misleading.
>
> Can anyone clarify this? I may just be misunderstanding the docs and/or the 
> recent discussions. Or it could be that the definition has changed around 
> that quoted paragraph and it needs to be updated.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

As far as my understanding goes, that rule should not apply. The
rationale I guess is that having that inconsistency helps eliminate
issues with dynamic properties and potential gotchas like these:

```js
class A {}
class B {}

var foo = {};
var bar = {};
foo.__proto__ = A.prototype;
bar.__proto__ = B.prototype;

for (var prop in foo) {
  bar[prop] = foo[prop];
}

// If this is false, then that's a problem.
assert(bar instanceof B);
```

Also, AFAICT, these should never throw, for the same reason:

```js
class A {}
var proto = '__proto__';
{
  __proto__: A.prototype
  [proto]: null
}
{
  __proto__: A.prototype
  ['__proto__']: null
}
```

-- 
Isiah Meadows
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question regarding duplicate computed __proto__ properties

[Fred Schott]

Filed as Bug 3510. Thanks for the confirmation, Allen.

—
Sent from Mailbox

On Sun, Jan 4, 2015 at 9:13 PM, Allen Wirfs-Brock 
wrote:

> On Jan 4, 2015 9:06 PM, Fred Schott  wrote:
>>
>> In Section B.3.1 on "__proto__ Property Names in Object Initializers" there 
>> is a paragraph explaining when duplicate properties will result in a syntax 
>> error. It says:
>>
>>> It is a Syntax Error if PropertyNameList of PropertyDefinitionList contains 
>>> any duplicate entries for "__proto__" and at least two of those entries 
>>> were obtained from productions of the form PropertyDefinition : 
>>> PropertyName : AssignmentExpression .
>>
>>
>> Where PropertyName is defined as: 
>>
>>> PropertyName[Yield,GeneratorParameter] :
>>>   LiteralPropertyName
>>>   [+GeneratorParameter] ComputedPropertyName
>>>   [~GeneratorParameter] ComputedPropertyName[?Yield]
>>>
>>> LiteralPropertyName :
>>>   IdentifierName
>>>   StringLiteral
>>>   NumericLiteral
>>
>>
>> That paragraph (using the definitions provided) seems to assert that it is a 
>> syntax error if there are any duplicate uses of __proto__ with an 
>> IdentifierName, StringLiteral, or ComputedPropertyName. To translate this 
>> into an example, it seems to assert that in ES6 this is not valid:
>>
>>> var obj = {
>>>   __proto__: somePrototype,
>>>   ["__proto__"]: somePrototype
>>> } 
>>>
>>> // Error: SyntaxError
> No, this is not supposed to be a syntax error.
>>
>>
>> Is that correct? Step 6 of Section B.3.1 explicitly states that the computed 
>> ["__proto__"] does not have the same special behavior as the literal 
>> property. But from my understanding of other es-discuss topics & resources, 
>> the restriction on duplicate "__proto__" properties also does not apply to 
>> computed properties. If that is true, then the quoted paragraph above seems 
>> to be incorrect or misleading.
>>
>> Can anyone clarify this? I may just be misunderstanding the docs and/or the 
>> recent discussions. Or it could be that the definition has changed around 
>> that quoted paragraph and it needs to be updated.
> The latter. Please file a bug at bugs.ecmascript.org___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Question regarding duplicate computed __proto__ properties

[Allen Wirfs-Brock]

On Jan 4, 2015 9:06 PM, Fred Schott  wrote:
>
> In Section B.3.1 on "__proto__ Property Names in Object Initializers" there 
> is a paragraph explaining when duplicate properties will result in a syntax 
> error. It says:
>
>> It is a Syntax Error if PropertyNameList of PropertyDefinitionList contains 
>> any duplicate entries for "__proto__" and at least two of those entries were 
>> obtained from productions of the form PropertyDefinition : PropertyName : 
>> AssignmentExpression .
>
>
> Where PropertyName is defined as: 
>
>> PropertyName[Yield,GeneratorParameter] :
>>   LiteralPropertyName
>>   [+GeneratorParameter] ComputedPropertyName
>>   [~GeneratorParameter] ComputedPropertyName[?Yield]
>>
>> LiteralPropertyName :
>>   IdentifierName
>>   StringLiteral
>>   NumericLiteral
>
>
> That paragraph (using the definitions provided) seems to assert that it is a 
> syntax error if there are any duplicate uses of __proto__ with an 
> IdentifierName, StringLiteral, or ComputedPropertyName. To translate this 
> into an example, it seems to assert that in ES6 this is not valid:
>
>> var obj = {
>>   __proto__: somePrototype,
>>   ["__proto__"]: somePrototype
>> } 
>>
>> // Error: SyntaxError

No, this is not supposed to be a syntax error.


>
>
> Is that correct? Step 6 of Section B.3.1 explicitly states that the computed 
> ["__proto__"] does not have the same special behavior as the literal 
> property. But from my understanding of other es-discuss topics & resources, 
> the restriction on duplicate "__proto__" properties also does not apply to 
> computed properties. If that is true, then the quoted paragraph above seems 
> to be incorrect or misleading.
>
> Can anyone clarify this? I may just be misunderstanding the docs and/or the 
> recent discussions. Or it could be that the definition has changed around 
> that quoted paragraph and it needs to be updated.

The latter. Please file a bug at bugs.ecmascript.org
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Question regarding duplicate computed __proto__ properties

[Fred Schott]

In Section B.3.1 on "__proto__ Property Names in Object Initializers"

there is a paragraph explaining when duplicate properties will result in a
syntax error. It says:

It is a Syntax Error if *PropertyNameList* of *PropertyDefinitionList*
> contains any duplicate entries for "__proto__" and at least two of those
> entries were obtained from productions of the form *PropertyDefinition* :
> *PropertyName* : *AssignmentExpression* .
>

Where *PropertyName *is defined as:

PropertyName[Yield,GeneratorParameter] :
>   LiteralPropertyName
>   [+GeneratorParameter] ComputedPropertyName
>   [~GeneratorParameter] ComputedPropertyName[?Yield]
>
> LiteralPropertyName :
>   IdentifierName
>   StringLiteral
>   NumericLiteral


That paragraph (using the definitions provided) seems to assert that it is
a syntax error if there are any duplicate uses of __proto__ with an
IdentifierName, StringLiteral, or ComputedPropertyName. To translate this
into an example, it seems to assert that in ES6 this is not valid:

var obj = {
>   __proto__: somePrototype,
>   ["__proto__"]: somePrototype
> }

// Error: SyntaxError


Is that correct? Step 6 of Section B.3.1 explicitly states that the
computed ["__proto__"] does not have the same special behavior as the
literal property. But from my understanding of other es-discuss topics &
resources, the restriction on duplicate "__proto__" properties also does
not apply to computed properties. If that is true, then the quoted
paragraph above seems to be incorrect or misleading.

Can anyone clarify this? I may just be misunderstanding the docs and/or the
recent discussions. Or it could be that the definition has changed around
that quoted paragraph and it needs to be updated.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Overriding the == operator, like in Java/Lua/Python/whatever.

[Gary Guo]

I agree that use equals is a better choice. If operator overloading is 
implemented, you may experience inconsistency (different instance of builtin 
boxed values would be unequal according to default semantics, while after 
overloaded == operator it becomes equal.)
Date: Sat, 3 Jan 2015 23:52:58 -0200
From: fakedme...@gmail.com
To: es-discuss@mozilla.org
Subject: Overriding the == operator, like in Java/Lua/Python/whatever.


  

  
  
I've been looking and looking and looking and I
  couldn't find a way to override == to make 2 different instances
  of MyPoint compare == if they have the same coordinates. (I
guess this also applies to String objects and stuff but I haven't
tested that)



So how do I do this?



(PS: yes, I know, Java has an .equals method, not overridable ==,
but it's basically the same thing)
  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Overriding the == operator, like in Java/Lua/Python/whatever.

[Gary Guo]

I agree that use equals is a better choice. If operator overloading is 
implemented, you may experience inconsistency (different instance of builtin 
boxed values would be unequal according to default semantics, while after 
overloaded == operator it becomes equal.)
Date: Sat, 3 Jan 2015 23:52:58 -0200
From: fakedme...@gmail.com
To: es-discuss@mozilla.org
Subject: Overriding the == operator, like in Java/Lua/Python/whatever.


  

  
  
I've been looking and looking and looking and I
  couldn't find a way to override == to make 2 different instances
  of MyPoint compare == if they have the same coordinates. (I
guess this also applies to String objects and stuff but I haven't
tested that)



So how do I do this?



(PS: yes, I know, Java has an .equals method, not overridable ==,
but it's basically the same thing)
  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Add to the list members

[Isiah Meadows]

> From: monolithed 
> To: es-discuss@mozilla.org
> Cc:
> Date: Sun, 4 Jan 2015 19:28:28 +0400
> Subject: Add to the list members
> Hi, please add me to the list members
>
>
>
>
> The best regards, Alexander
> https://github.com/monolithed

Here's you a link:
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

[Isiah Meadows]

Forgot to retitle it.
On Jan 3, 2015 9:44 PM, "Isiah Meadows"  wrote:

> > From: Axel Rauschmayer 
> > To: bren...@mozilla.org
> > Cc: es-discuss list 
> > Date: Sun, 4 Jan 2015 03:17:54 +0100
> > Subject: Re: Implicit coercion of Symbols
> > Does it have to be a Reflect.* method? It could be
> `Symbol.prototype.getDescription()` or a getter.
> >
> >> On 04 Jan 2015, at 02:25, Brendan Eich  wrote:
> >>
> >> Rick Waldron wrote:
> >>>
> >>> That example above is pretty compelling for throw always consistency.
> >>
> >>
> >> With a new Reflect.* API for converting a symbol to its
> diagnostic/debugging string?
> >>
> >> If you agree, please file a bugs.ecmascript.org ticket.
> >>
> >> /be
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > --
> > Dr. Axel Rauschmayer
> > a...@rauschma.de
> > rauschma.de
>
> A good name for such a getter would be, IMO,
> `Symbol.prototype.description`. It would also seem to fit with some other
> common JS idioms, such as `Array.prototype.length`, etc. It also feels
> clearer and cleaner as a getter than an instance method or function.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Implicit coercion of Symbols

[Brendan Eich]

Claude Pache wrote:

Now, it will be argued that it would be a precedent to make such a distinction 
between implicit and explicit coercion, for, until ES5, there is none.


Kind of there all along, as noted up-thread:

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"

But I take your point.


But, precisely, pervasive implicit coercion is often thought to be a mistake in 
the design of JavaScript (it hides bugs), while coercion in general is indeed 
useful (e.g., for debugging purpose, as pointed Alex in this thread).


*Explicit* coercion in general is useful. What's "explicit"? It could be 
console.log is an explicit-enough gesture. It does more than just 
ToString on its parameters today, IINM (at least in some browsers).



  Now, as we are evolving the language, it is good to limit the scope of the 
bad implicit coercion behaviour (such as the abstract operation `ToString()` of 
the spec), but to consolidate the functionality of the existing explicit 
coercion functions (such as `String()`).


Yes, this is the rationale for ES6's symbol handling today.


If there is a need to directly expose the implicit coercion to string operation 
to user code, `Reflect.toString()` is a natural fit for that, together with 
`Reflect.toBoolean()`, `Reflect.toPropertyKey()`,  `Reflect.toPrimitive(_, 
hint)`, etc.


Yup; ES7 fodder at this stage.

I think it's very unlikely anyone will try to patch ES6 over the 
trade-offs among consistencies that this thread has illuminated. Thanks,


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Maps and sets and insertion order

[Axel Rauschmayer]

I think it’s great that maps and sets honor insertion order.

Two ideas:

* Sets: Could the keys used for `Set.prototype.entries()` and 
`Set.prototype.forEach()` be the position of an element? IMO that’d be more 
useful than using the element as both key and value.

* Maps: Long-term, I’d love to be able to access and delete entries by position.

Axel

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Implicit coercion of Symbols

[Claude Pache]

> Le 4 janv. 2015 à 03:18, Rick Waldron  a écrit :
> 
> 
> 
> On Sat Jan 03 2015 at 8:25:40 PM Brendan Eich  wrote:
> Rick Waldron wrote:
> > That example above is pretty compelling for throw always consistency.
> 
> With a new Reflect.* API for converting a symbol to its
> diagnostic/debugging string?
> 
> If you agree, please file a bugs.ecmascript.org ticket.
> 
> 
> https://bugs.ecmascript.org/show_bug.cgi?id=3509
> 

I think that it is asking for the wrong consistency. There is another 
consistency to be wanted, namely:

   String(sym) === sym.toString()

(assuming that `Symbol.prototype.toString` isn't sabotaged by user code, of 
course). Indeed:

* `String(sym)` and `sym.toString()` are *explicit* coercions to string; while
* `sym + ""` triggers an *implicit* coercion to string (in that very case, 
preceded by a coercion to primitive, but it's not the subject).

Now, it will be argued that it would be a precedent to make such a distinction 
between implicit and explicit coercion, for, until ES5, there is none. But, 
precisely, pervasive implicit coercion is often thought to be a mistake in the 
design of JavaScript (it hides bugs), while coercion in general is indeed 
useful (e.g., for debugging purpose, as pointed Alex in this thread). Now, as 
we are evolving the language, it is good to limit the scope of the bad implicit 
coercion behaviour (such as the abstract operation `ToString()` of the spec), 
but to consolidate the functionality of the existing explicit coercion 
functions (such as `String()`).

If there is a need to directly expose the implicit coercion to string operation 
to user code, `Reflect.toString()` is a natural fit for that, together with 
`Reflect.toBoolean()`, `Reflect.toPropertyKey()`,  `Reflect.toPrimitive(_, 
hint)`, etc.

—Claude


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Add to the list members

[monolithed]

Hi, please add me to the list members




The best regards, Alexander
https://github.com/monolithed
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Octal escape sequences in string and regexp literals

[Claude Pache]

> Le 4 janv. 2015 à 00:44, Caitlin Potter  a écrit :
> 
>> I agree on that point, and therefore I didn't make any refactoring argument.
>> 
> I was referring specifically to C12 (and one other, IIRC) on bug 3477
> 

(For reference, bug 3477 C12 is here: 
https://bugs.ecmascript.org/show_bug.cgi?id=3477#c12 )

In that case, I disagree on that point, but I didn't make any refactoring 
argument. I mean: the two questions I asked in the beginning of the present 
thread are unrelated to the particular refactoring hazard mentioned in bug 3477 
comment 12.

—Claude

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: {Spam?} Re: Implicit coercion of Symbols

[Brendan Eich]

Andrea Giammarchi wrote:
A generic description-aware `Reflect.describe(genericObject)`like 
approach seems way more useful for logging annd debugging purpose than 
a footgun in the wild.


Good idea, should find an ES7 champion. If we had this, I think we could 
have made String(sym) throw, and perhaps would have. Should have :-P.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Overriding the == operator, like in Java/Lua/Python/whatever.

[Andrea Giammarchi]

yep, I'm afraid this is described as such in the old post (and in specs)
too:

> Return true if x and y refer to the same object. Otherwise, return false

in your Point cases you can add `.equals(otherPoint)` in Point prototype
otherwise use an utility that does similar thing Java does.

Regards



On Sun, Jan 4, 2015 at 3:16 AM, Michał Wadas  wrote:

> It won't help because objects are ALWAYS compared by their identity.
> valeOf or toString will be used only in case of comparing object with
> primitive.
> 4 sty 2015 03:10 "Salvador de la Puente González" 
> napisał(a):
>
> Reimplement Object#valueOf() returning a string representation of your
>> object.
>>
>> See
>> http://webreflection.blogspot.com.es/2010/10/javascript-coercion-demystified.html?m=1
>>
>> Hope it helps.
>> On 4 Jan 2015 02:53, "Soni L."  wrote:
>>
>>>  I've been looking and looking and looking and I couldn't find a way to
>>> override == to make 2 different instances of MyPoint compare == if they
>>> have the same coordinates. (I guess this also applies to String objects
>>> and stuff but I haven't tested that)
>>>
>>> So how do I do this?
>>>
>>> (PS: yes, I know, Java has an .equals method, not overridable ==, but
>>> it's basically the same thing)
>>>
>>> ___
>>> 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
>>
>>
> ___
> 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: generator libraries

[Gary Guo]

Actually I wrote pretty much the similar one with less functions (since I 
haven't need to use them yet), but with different name (I use Stream, since my 
idea are simply from Java 8's Stream AI) 
https://gist.githubusercontent.com/nbdd0121/11158010032648c32e6f/raw/0bcd6c77f262f2bddc56d2f4ebd74aa8fd2d3267/Stream.js

From: rbuck...@chronicles.org
To: m...@aaron-powell.com; r.mark.volkm...@gmail.com; es-discuss@mozilla.org
Subject: RE: generator libraries
Date: Sun, 4 Jan 2015 06:08:51 +










I wrote http://github.com/rbuckton/queryjs  
  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Implicit coercion of Symbols

[Andrea Giammarchi]

Alex, like I've said:

`log({__proto__:null})` and welcome crashes of the server, if that's a real
concern in this form.

Is it that wrong to assume that if `console.log({__proto__:null})` is
capable of handling non Objects and print a meaningful output, so should
any other logger implemented on user-land?

'cause logging a part there's still no case where implicit or explicit
Symbol cast makes any sense.

It's like `object['undefined']` where `undefined` is implicitly created by
some missed property which has been somehow problematic for long time.

A generic description-aware `Reflect.describe(genericObject)`like approach
seems way more useful for logging annd debugging purpose than a footgun in
the wild.

Regards



On Sun, Jan 4, 2015 at 3:41 AM, Alex Kocharin  wrote:

>
> 04.01.2015, 04:58, "Brendan Eich" :
>
> Alex Kocharin wrote:
>
>   The code will be incorrect if you pass any regular object in there.
>  Why should symbol be any different?
>  For me, its throwing behavior is just another thing that could crash
>  server-side node.js process for no good reason.
>
> No good reason? Wrong.
>
> Just because bugs pass without exception doesn't mean we must continue
> the "tradition".
>
>
> It isn't always a bug. People could cast something to a string for
> debugging purposes like this:
>
> ```
> function log(anything) {
>   process.stdout.write(new Date().toJSON() + ' - ' + anything + '\n')
> }
> ```
>
> Right now it'll never throw. Well, unless you override `.toString()` to
> throw, which I've never seen to be done intentionally.
>
> With throwing Symbols we'll have innocuous-looking code which will cause
> an exception. And since javascript developers don't usually have a history
> of using throw..catch everywhere (some even avoid it for performance
> reasons), the consequences could be quite dire.
>
> Thus, every single code snippet that use type casting will have to either
> be wrapped with try..catch or checked for `symbol` explicitly. Maybe we'll
> write libraries called "castAnythingToStringSafely" because of that (like
> json-stringify-safe is created because JSON.stringify throws). And it'll
> surely make things worse for the beginners who don't know language well
> enough to remember to add those workarounds everywhere.
>
> So yes, I think that the existence of the errors you mentioned isn't a
> good reason to throw. There is no way for the interpreter to check
> developer intentions, and the casting can be used for good.
>
> Also, if you want to prevent mistakes like `object['blah' + symbol]`,
> linters could be changed to forbid/warn about concatenation inside property
> names. It's their job to warn about suspicious behavior, javascript spec
> should stay as simple as possible imho.
>
>
> ___
> 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

[Brendan Eich]

Alex Kocharin wrote:


 My point is: concatenating Symbols with other strings have
legitimate
 uses.

Name one.


I did name one in another message. Logging.


That's a use-case for some way (could be concatenation, but as noted the 
downside risk is huge; could be a new Reflect method) to convert symbol 
to string. Explicit is better than implicit. Saying "Logging" does not 
say "allow implicit symbol to string conversion".


I agree that String(sym) working where ''+sym throws is funky (my word 
in this thread). We could make both throw, with a Reflect.symbolToString 
or whatever it might be called. ES6 is about out of time, this may not 
fly, but if it is possible it has to be done quickly.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss