Propose simpler string constant

Thomas thomasjamesfoster at bigpond.com
Wed Dec 16 11:20:15 UTC 2015


IMHO it'd be a huge mistake to not use symbols for enums. 

In my head this:

const colours = enum {
  Red,
  Yellow,
  Green,
  Blue
}

should 'desugar' to something like this in ES6:

const colours = {
  Red: Symbol('Red'),
  Yellow: Symbol('Yellow'),
  Green: Symbol('Green'),
  Blue: Symbol('Blue')
}

Thomas 

> On 16 Dec 2015, at 10:02 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> 
> FWIW I think If an enum should hold a unique value either "symbol" or a new "enum" type, otherwise I think "number" would be easier way to go.
> 
> Regards
> 
>> On Wed, Dec 16, 2015 at 12:20 AM, kdex <kdex at kdex.de> wrote:
>> Honestly,
>> 
>> ```js
>>     const ADD_ALL_THE_STUFF = "ADD_ALL_THE_STUFF";
>> ```
>> 
>> doesn't seem like a intended approach anyway, even if there was a shorter syntax. `Symbol()` seems to be the better choice if the objective is to manage references whose values indicates special semantics; I have yet to see a use case where a string turns out to be beneficial. Semantically, what should
>> 
>> ```js
>> typeof (enum {
>>     APPLE,
>>     ORANGE,
>>     GRAPE
>> }).APPLE;
>> ```
>> 
>> evaluate to? A `"symbol"` called with its identifier, an identifier-valued `"string"`, an integer-valued `"number"`?
>> 
>> 
>>> On 16.12.2015 00:00, Jordan Harband wrote:
>>> Correct, when `const foo;` throws, my concern doesn't exist. The concern I was talking about is if this initial suggestion went through, and `const foo;` would become `const foo = 'foo';`, that a new refactoring hazard would be created - which is the entire reason `const foo;` throws as-is.
>>> 
>>> Agreed that an `enum` construct would be very useful.
>>> 
>>> On Tue, Dec 15, 2015 at 11:56 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>>>> Jordan AFAIK you can't have undefined const declaration so your concern is unfounded.
>>>> 
>>>> However, I'm pretty sure what Brendan says **is** indeed what developers want so I'd +1 that without problems.
>>>> 
>>>> Regards
>>>> 
>>>>> On Tue, Dec 15, 2015 at 4:44 PM, Jordan Harband <ljharb at gmail.com> wrote:
>>>>> That seems hazardous - if someone is converting a "var" codebase to "const" and "let", and they convert `var foo;` to `const foo;` expecting it to be undefined, the current TDZ error will be much more helpful to them than a silent change of meaning in their code to `const foo = 'foo';`.
>>>>> 
>>>>> On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf <mozilla at turtlebyte.com> wrote:
>>>>>> A common pattern I see is this:
>>>>>> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>>>>>> 
>>>>>> Would it be helpful to allow a shorter version of this to be:
>>>>>> const ADD_ALL_THE_STUFF
>>>>>> 
>>>>>> Rather than have that just be forever undefined, it could automatically refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151216/aecf8936/attachment-0001.html>


More information about the es-discuss mailing list