Why ES6 introduced classes yet `Symbol` not to be used with `new`?
krissiegel at gmail.com
Mon Aug 15 05:33:25 UTC 2016
Because, to be consistent with Number/String/Boolean you would expect `new
> Symbol()` to create a Symbol wrapper object.
Currently Symbol is the only primitive that can't be converted to a string
through the use of the + operator, so why the consistency in one place and
the lack thereof in another? I understand there isn't really a meaningful
representation of Symbol() as a string but I didn't see any particular
reason in my cursory look at the past notes for it to throw an exception so
I've been curious.
But we anticipated that if `new Symbol` was allowed many devs (who lacked
> an understanding of the difference between primitive values and wrapper
> objects for primitive values) would code `new Symbol()` with the
> expectation that they were creating a Symbol value. This would be a silent
> bug so we disallowed `new Symbol()`.
Forgive me for the ignorance but what kind of bug would this introduce?
Since Symbol() is already an oddball compared to all other built-in objects
and primitives would it have been so bad to simply make `new Symbol()`
equate to `Symbol()`? I'm not sure you'll get developers to understand the
difference between primitives and wrapper objects (still haven't found one
yet who understands this in my inner-circle of JS devs that I know at
On Sun, Aug 14, 2016 at 9:18 PM, Domenic Denicola <d at domenic.me> wrote:
> I believe, but am not sure, that we also decided we would follow that
> pattern for any future primitive types, since in general constructing
> wrapper objects is a bad idea. (I want to say that wrapper objects
> themselves are a bad idea, but I think the conclusion was more subtle than
> that... they are an important part of the semantics, it's just unfortunate
> that they're so easy to create.)
> If some enterprising person wants to dig through the meeting notes, there
> might be some hints there...
> > From: Allen Wirfs-Brock [mailto:allen at wirfs-brock.com]
> > Because, to be consistent with Number/String/Boolean you would expect
> `new Symbol()` to create a Symbol wrapper object. But we anticipated that
> if `new Symbol` was allowed many devs (who lacked an understanding of the
> difference between primitive values and wrapper objects for primitive
> values) would code `new Symbol()` with the expectation that they were
> creating a Symbol value. This would be a silent bug so we disallowed `new
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss