Interesting. 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 least). On Sun, Aug 14, 2016 at 9:18 PM, Domenic Denicola <[email protected]> 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:[email protected]] > > > > 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 > Symbol()`. > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
