github at esdiscuss.org (2013-07-12T02:26:59.134Z)
Le 13 avr. 2013 ? 15:25, Andreas Rossberg <rossberg at google.com> a ?crit :
> On 13 April 2013 13:36, Claude Pache <claude.pache at gmail.com> wrote:
>>
>>
>> Le 13 avr. 2013 ? 09:56, Andreas Rossberg <rossberg at google.com> a ?crit :
>>
>>> On 13 April 2013 00:35, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>>>
>>>> Regarding #3
>>>>
>>>> The biggest footgun is if `new Symbol()` creates a Symbol wrapper. However, `new Symbol()` returning a primitive values would be unlike anything we currently have in the language
>>>
>>> I agree, it has to be the former. But what footgun are you seeing
>>> there? Any attempt to use a wrapper as a key throws under the
>>> agreed-upon semantics, so I don't see the issue.
>>
>> As a JS programmer, I will be very tempted to write `new Symbol` to get a new symbol. The issue is that you get an error in a different line of code from where the problem lies, and you have to be fond of the subtle distinction between value and object wrapper (which is a feature we never use in our daily coding) to understand what is happening without external help.
>
> While that is true, and unfortunate, it also is the case for pretty
> much every other mistake you can make in JavaScript (or any dynamic
> language, for that matter) -- and there are far more subtle ones in
> that class. So I'm not convinced that this particular case justifies
> special casing.
The idea is simply to avoid adding footguns for new features, even if we can't remove the existing ones.
Regarding the issue discussed here, let me elaborate:
Until now, `new Primitive`, where `Primitive` is `Number`, `String` or `Boolean` is, in practice, not a problem, because you never need to create a new number, string or boolean that way. (You can use `Primitive` as a function for typecasting, but it is not felt as the same thing as creating a new value.) Things are different with symbols, so the `new Symbol` footgun is practically a new type of footgun.
Note also that `new Date`, `new RegExp`, `new Map`, etc., work as intuitively expected, and, if I have correctly followed the last discussions, `function* gen() { /* ... */}; myIterator = new gen` (meaning: "I want to get a *new* iterator from that generator function") would also work.
I do agree that special-casing should be avoided. Therefore, I think we should make a rule: `new Primitive` should throw for primitive types, except for legacy numbers, booleans and strings (Don't Break The Web) for which it is not a real issue.
Le 13 avr. 2013 à 15:25, Andreas Rossberg <rossberg at google.com> a écrit : > On 13 April 2013 13:36, Claude Pache <claude.pache at gmail.com> wrote: >> >> >> Le 13 avr. 2013 à 09:56, Andreas Rossberg <rossberg at google.com> a écrit : >> >>> On 13 April 2013 00:35, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >>>> <snip> >>>> >>>> Regarding #3 >>>> >>>> The biggest footgun is if >>>> new Symbol() >>>> creates a Symbol wrapper. However, >>>> new Symbol() >>>> returning a primitive values would be unlike anything we currently have in >>>> the language >>> >>> I agree, it has to be the former. But what footgun are you seeing >>> there? Any attempt to use a wrapper as a key throws under the >>> agreed-upon semantics, so I don't see the issue. >> >> As a JS programmer, I will be very tempted to write `new Symbol` to get a new symbol. The issue is that you get an error in a different line of code from where the problem lies, and you have to be fond of the subtle distinction between value and object wrapper (which is a feature we never use in our daily coding) to understand what is happening without external help. > > While that is true, and unfortunate, it also is the case for pretty > much every other mistake you can make in JavaScript (or any dynamic > language, for that matter) -- and there are far more subtle ones in > that class. So I'm not convinced that this particular case justifies > special casing. > > /Andreas The idea is simply to avoid adding footguns for new features, even if we can't remove the existing ones. Regarding the issue discussed here, let me elaborate: Until now, `new Primitive`, where `Primitive` is `Number`, `String` or `Boolean` is, in practice, not a problem, because you never need to create a new number, string or boolean that way. (You can use `Primitive` as a function for typecasting, but it is not felt as the same thing as creating a new value.) Things are different with symbols, so the `new Symbol` footgun is practically a new type of footgun. Note also that `new Date`, `new RegExp`, `new Map`, etc., work as intuitively expected, and, if I have correctly followed the last discussions, `function* gen() { /* ... */}; myIterator = new gen` (meaning: "I want to get a *new* iterator from that generator function") would also work. I do agree that special-casing should be avoided. Therefore, I think we should make a rule: `new Primitive` should throw for primitive types, except for legacy numbers, booleans and strings (Don't Break The Web) for which it is not a real issue. —Claude