'new Number' and 'new String' are also functionally useful to a degree -
I've had reason to use both in my compiler's runtime library, either to
allow returning a value from a constructor or to assign properties to a
number.

It sounds like 'new Symbol' will never be functionally useful because it
won't actually produce a valid symbol, in the wrapper case? If so, I agree
that it makes sense to ensure that developers never try to use that
particular construct and expect it to work. I also agree that in JS, my
first instinct would be 'new Symbol' to get a symbol, so having that
silently do the wrong thing would not be desirable. Poisoning toString
sounds like an okay solution too, as long as it is relatively
straightforward to figure out *why* your toString has become poisoned -
given no toString, it becomes kind of difficult to figure out (via stock JS
debugging tools) that 'oh, I created a symbol object wrapper instead of a
symbol' is your problem. (This is, to be fair, also a problem with the
other primitive wrapper objects)


On Sat, Apr 13, 2013 at 7:29 AM, Claude Pache <claude.pache at gmail.com>wrote:

>
>
> 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
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
-kg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130413/01551e77/attachment.html>

`new Number` and `new String` are also functionally useful to a degree -
I've had reason to use both in my compiler's runtime library, either to
allow returning a value from a constructor or to assign properties to a
number.

It sounds like `new Symbol` will never be functionally useful because it
won't actually produce a valid symbol, in the wrapper case? If so, I agree
that it makes sense to ensure that developers never try to use that
particular construct and expect it to work. I also agree that in JS, my
first instinct would be `new Symbol` to get a symbol, so having that
silently do the wrong thing would not be desirable. Poisoning `toString`
sounds like an okay solution too, as long as it is relatively
straightforward to figure out *why* your `toString` has become poisoned -
given no `toString`, it becomes kind of difficult to figure out (via stock JS
debugging tools) that 'oh, I created a symbol object wrapper instead of a
symbol' is your problem. (This is, to be fair, also a problem with the
other primitive wrapper objects)