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 <[email protected]>
> 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 <[email protected]> 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
>>> <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>>>> 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
>>>>>> [email protected]
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> 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
