Re: Propose simpler string constant

[Brendan Eich]

Hi Rick, thanks to you and Mike for drafting. I will read and comment more
when I have time, but I wanted to channel the Twitter-ghost of Dave Herman:

"we should start from pattern matching and work our way from there into the
kinds of datatypes we want to match on"

I hear wycats and bterlson are working on pattern matching. Ccing them.

/be

On Thu, Dec 17, 2015 at 1:42 PM Rick Waldron  wrote:

> On Thu, Dec 17, 2015 at 3:33 PM Steve Kinney 
> wrote:
>
>> I did some initial thinking about this and looked at Rust and Swift as
>> prior art. I started something similar to what was being discussed but came
>> across some edge cases as I went along.
>>
>> https://github.com/stevekinney/ecmascript-enumerations
>>
>> Right now, it's just a draft of notes and thoughts, but I am working on a
>> draft implementation with Sweet.js.
>>
>
> I had originally had values with implicit ordinal numbers, but Mike
> Pennisi (co-author) and I agreed that with Symbol there isn't much benefit
> to making the raw value a number.
>
> Anyway, this is the WIP http://rwaldron.github.io/enum-definitions/
>
>
> Rick
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[miguel de Sousa]

Thanks for popping in Brendan!

On Fri, 18 Dec 2015 2:41 pm Bob Myers  wrote:

> One could do worse than look at Python's enums:
> https://docs.python.org/3/library/enum.html.
>
> --
> Bob
>
> On Fri, Dec 18, 2015 at 3:12 AM, Rick Waldron 
> wrote:
>
>>
>>
>> On Thu, Dec 17, 2015 at 3:33 PM Steve Kinney 
>> wrote:
>>
>>> I did some initial thinking about this and looked at Rust and Swift as
>>> prior art. I started something similar to what was being discussed but came
>>> across some edge cases as I went along.
>>>
>>> https://github.com/stevekinney/ecmascript-enumerations
>>>
>>> Right now, it's just a draft of notes and thoughts, but I am working on
>>> a draft implementation with Sweet.js.
>>>
>>
>> I had originally had values with implicit ordinal numbers, but Mike
>> Pennisi (co-author) and I agreed that with Symbol there isn't much benefit
>> to making the raw value a number.
>>
>> Anyway, this is the WIP http://rwaldron.github.io/enum-definitions/
>>
>>
>> Rick
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Alexander Jones]

ums would be a combination of the
>>> above approaches, with some additions:
>>>
>>> * An enum can be a declaration or an expression.
>>> * The body of an enum consists of a new lexical scope.
>>> * Enum members are standard JavaScript identifiers.
>>> * Enum members are automatically assigned an incrementing integer value,
>>> starting at zero.
>>> * Enum members can be explicitly assigned to an integer value, or
>>> another enum value.
>>> * Within the body of an enum, Enum members can be accessed in the
>>> initializer without qualification.
>>> * Within the body of an enum, Enum members are lexically declared names
>>> and cannot be accessed before they are defined (TDZ).
>>> * An enum declaration can be called as a function to convert a string or
>>> numeric value into the enum value, making enum types distinct from numbers
>>> and from each other. [1]
>>> * The result of `typeof` on an enum value is `enum`.
>>> * Enum values support (at least) the following operators, returning an
>>> enum value of the same type: + (unary), - (unary), ~, + (binary), -
>>> (binary), | (binary), & (binary), ^ (binary).
>>> * Any binary operation between two enums of different types is a
>>> TypeError. [1]
>>> * Any binary operation between an enum and a number first converts the
>>> number to the enum type. If the number is not an integer it is a TypeError.
>>> * Any binary operation between an enum and a string first converts the
>>> enum into the string value for that enum based on the enum member's
>>> JavaScript identifier (if present), or the string representation of its
>>> integer numeric value. [2]
>>> * Calling Number() with an enum value as its first argument returns its
>>> underlying number value.
>>> * Calling String() with an enum value as its first argument returns the
>>> string value for the enum member that defines the number (if present), or
>>> the string representation of its integer numeric value. [2]
>>> * Calling the valueOf() instance method on an enum value has the same
>>> effect as Number() above.
>>> * Calling the toString() instance method on an enum value has the same
>>> effect as String() above. [2]
>>> * Two enum members on the same enum or differing enum types with the
>>> same underlying integer value are equivalent (==) but not
>>> strictly/reference equivalent (===). [1]
>>>
>>> I think these rules could satisfy both anyone who needs enum values to
>>> be numeric (to support bitwise operations, bitmasks, ordinal indices, etc.)
>>> and those that would like enum values to be unique in a fashion similar to
>>> using Symbol().
>>>
>>> [1] We have noticed in TypeScript some issues with Symbol-like
>>> equivalence with enums if you have two versions of the same module in
>>> NodeJS due to specific version dependencies, where you could have
>>> a.Color.Red !== b.Color.Red if *a* and *b* are different versions of the
>>> same module. Generally I think having enum values just really be numbers
>>> and not differing between == and === is less of a footgun.
>>>
>>> [2] If enum values of different types should be === to each other, you
>>> should not be able to get a different result when you call .ToString(). In
>>> that case, we could add a static `getName` method to the enum type to get
>>> the string value for an enum.
>>>
>>> Ron
>>>
>>> > -Original Message-
>>> > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
>>> > Brendan Eich
>>> > Sent: Wednesday, December 16, 2015 10:04 AM
>>> > To: Alican Çubukçuoğlu <alicancubukcuo...@gmail.com>; es-
>>> > disc...@mozilla.org
>>> > Subject: Re: Re: Propose simpler string constant
>>> >
>>> > On Wed, Dec 16, 2015 at 9:41 AM Alican Çubukçuoğlu
>>> > <alicancubukcuo...@gmail.com <mailto:alicancubukcuo...@gmail.com> >
>>> > wrote:
>>> >
>>> >
>>> >   How are enums declared?
>>> >   ```javascript
>>> >   let myVar = 13;
>>> >   enum myEnum = {Red, Green, Blue};
>>> >
>>> >
>>> > No `=` between name and `{`.
>>> >
>>> > Enumerator scope is a good question. Clearly we do not want global
>>> scope.
>>> > Rather, as a declaration immedicately contained by a block or top
>>> > level, we want lexical scope for the enum name -- and (I think) for
>>> the enumerators'
>>> > individual names.
>>> >
>>> > What about enumerator name scope for enum in class, without `static`?
>>> > I'm not sure, but precedent says that the enumerator names define
>>> > prototype properties.
>>> >
>>> > Expression as well as declaration `enum` form follows class and
>>> > function precedent. Expression form requires a reserved identifier
>>> > (not sym or sum or whatever), which `enum` has been forever,
>>> fortunately.
>>> >
>>> > I agree symbol values by default, with ` = 0` or some other number
>>> > than
>>> > 0 after the first enumerator name, looks confusing. Recall the first
>>> > use-case in the o.p. was (implicit, should rather be explicit)
>>> > reflection on the string value that spells the enumerator name.
>>> >
>>> > /be
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> <javascript:_e(%7B%7D,'cvml','es-discuss@mozilla.org');>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Alexander Jones]

 converts the
> number to the enum type. If the number is not an integer it is a TypeError.
> * Any binary operation between an enum and a string first converts the
> enum into the string value for that enum based on the enum member's
> JavaScript identifier (if present), or the string representation of its
> integer numeric value. [2]
> * Calling Number() with an enum value as its first argument returns its
> underlying number value.
> * Calling String() with an enum value as its first argument returns the
> string value for the enum member that defines the number (if present), or
> the string representation of its integer numeric value. [2]
> * Calling the valueOf() instance method on an enum value has the same
> effect as Number() above.
> * Calling the toString() instance method on an enum value has the same
> effect as String() above. [2]
> * Two enum members on the same enum or differing enum types with the same
> underlying integer value are equivalent (==) but not strictly/reference
> equivalent (===). [1]
>
> I think these rules could satisfy both anyone who needs enum values to be
> numeric (to support bitwise operations, bitmasks, ordinal indices, etc.)
> and those that would like enum values to be unique in a fashion similar to
> using Symbol().
>
> [1] We have noticed in TypeScript some issues with Symbol-like equivalence
> with enums if you have two versions of the same module in NodeJS due to
> specific version dependencies, where you could have a.Color.Red !==
> b.Color.Red if *a* and *b* are different versions of the same module.
> Generally I think having enum values just really be numbers and not
> differing between == and === is less of a footgun.
>
> [2] If enum values of different types should be === to each other, you
> should not be able to get a different result when you call .ToString(). In
> that case, we could add a static `getName` method to the enum type to get
> the string value for an enum.
>
> Ron
>
> > -Original Message-
> > From: es-discuss [mailto:es-discuss-boun...@mozilla.org <javascript:;>]
> On Behalf Of
> > Brendan Eich
> > Sent: Wednesday, December 16, 2015 10:04 AM
> > To: Alican Çubukçuoğlu <alicancubukcuo...@gmail.com <javascript:;>>; es-
> > disc...@mozilla.org <javascript:;>
> > Subject: Re: Re: Propose simpler string constant
> >
> > On Wed, Dec 16, 2015 at 9:41 AM Alican Çubukçuoğlu
> > <alicancubukcuo...@gmail.com <javascript:;>  alicancubukcuo...@gmail.com <javascript:;>> >
> > wrote:
> >
> >
> >   How are enums declared?
> >   ```javascript
> >   let myVar = 13;
> >   enum myEnum = {Red, Green, Blue};
> >
> >
> > No `=` between name and `{`.
> >
> > Enumerator scope is a good question. Clearly we do not want global scope.
> > Rather, as a declaration immedicately contained by a block or top
> > level, we want lexical scope for the enum name -- and (I think) for the
> enumerators'
> > individual names.
> >
> > What about enumerator name scope for enum in class, without `static`?
> > I'm not sure, but precedent says that the enumerator names define
> > prototype properties.
> >
> > Expression as well as declaration `enum` form follows class and
> > function precedent. Expression form requires a reserved identifier
> > (not sym or sum or whatever), which `enum` has been forever, fortunately.
> >
> > I agree symbol values by default, with ` = 0` or some other number
> > than
> > 0 after the first enumerator name, looks confusing. Recall the first
> > use-case in the o.p. was (implicit, should rather be explicit)
> > reflection on the string value that spells the enumerator name.
> >
> > /be
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <javascript:;>
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Rick Waldron]

On Wed, Dec 16, 2015 at 6:20 AM Thomas 
wrote:

> 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')
> }
>
>
When Brendan mentioned enum earlier in this thread I started writing a
proposal, which has evolved into exactly this. I should have something
worth reading by next week.

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Steve Kinney]

I did some initial thinking about this and looked at Rust and Swift as
prior art. I started something similar to what was being discussed but came
across some edge cases as I went along.

https://github.com/stevekinney/ecmascript-enumerations

Right now, it's just a draft of notes and thoughts, but I am working on a
draft implementation with Sweet.js.

On Thu, Dec 17, 2015 at 1:03 PM, Rick Waldron 
wrote:

>
>
> On Wed, Dec 16, 2015 at 7:27 AM Thomas 
> wrote:
>
>> Out of curiosity, is anyone working on a proposal for enum? Given the
>> keyword has been reserved for so long, it seems a little strange for a
>> proposal not to be floating around - unless I've missed something.
>>
>
> Yes. It's an early draft, but I will get it onto github as soon as
> possible.
>
> Rick
>
>
>> > On 16 Dec 2015, at 10:31 PM, Coroutines  wrote:
>> >
>> >> On Wed, Dec 16, 2015 at 3:20 AM, Thomas 
>> wrote:
>> >> 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
>> >
>> > This person gets it. +1  :-)
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Rick Waldron]

On Thu, Dec 17, 2015 at 3:33 PM Steve Kinney  wrote:

> I did some initial thinking about this and looked at Rust and Swift as
> prior art. I started something similar to what was being discussed but came
> across some edge cases as I went along.
>
> https://github.com/stevekinney/ecmascript-enumerations
>
> Right now, it's just a draft of notes and thoughts, but I am working on a
> draft implementation with Sweet.js.
>

I had originally had values with implicit ordinal numbers, but Mike Pennisi
(co-author) and I agreed that with Symbol there isn't much benefit to
making the raw value a number.

Anyway, this is the WIP http://rwaldron.github.io/enum-definitions/


Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Re: Propose simpler string constant

[Ron Buckton]

ort bitwise operations, bitmasks, ordinal indices, etc.) and 
those that would like enum values to be unique in a fashion similar to using 
Symbol().

[1] We have noticed in TypeScript some issues with Symbol-like equivalence with 
enums if you have two versions of the same module in NodeJS due to specific 
version dependencies, where you could have a.Color.Red !== b.Color.Red if *a* 
and *b* are different versions of the same module. Generally I think having 
enum values just really be numbers and not differing between == and === is less 
of a footgun.

[2] If enum values of different types should be === to each other, you should 
not be able to get a different result when you call .ToString(). In that case, 
we could add a static `getName` method to the enum type to get the string value 
for an enum.

Ron

> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of 
> Brendan Eich
> Sent: Wednesday, December 16, 2015 10:04 AM
> To: Alican Çubukçuoğlu <alicancubukcuo...@gmail.com>; es- 
> disc...@mozilla.org
> Subject: Re: Re: Propose simpler string constant
> 
> On Wed, Dec 16, 2015 at 9:41 AM Alican Çubukçuoğlu 
> <alicancubukcuo...@gmail.com <mailto:alicancubukcuo...@gmail.com> >
> wrote:
> 
> 
>   How are enums declared?
>   ```javascript
>   let myVar = 13;
>   enum myEnum = {Red, Green, Blue};
> 
> 
> No `=` between name and `{`.
> 
> Enumerator scope is a good question. Clearly we do not want global scope.
> Rather, as a declaration immedicately contained by a block or top 
> level, we want lexical scope for the enum name -- and (I think) for the 
> enumerators'
> individual names.
> 
> What about enumerator name scope for enum in class, without `static`?
> I'm not sure, but precedent says that the enumerator names define 
> prototype properties.
> 
> Expression as well as declaration `enum` form follows class and 
> function precedent. Expression form requires a reserved identifier 
> (not sym or sum or whatever), which `enum` has been forever, fortunately.
> 
> I agree symbol values by default, with ` = 0` or some other number 
> than
> 0 after the first enumerator name, looks confusing. Recall the first 
> use-case in the o.p. was (implicit, should rather be explicit) 
> reflection on the string value that spells the enumerator name.
> 
> /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Propose simpler string constant

[Brendan Eich]

On Wed, Dec 16, 2015 at 9:41 AM Alican Çubukçuoğlu <
alicancubukcuo...@gmail.com> wrote:

> How are enums declared?
> ```javascript
> let myVar = 13;
> enum myEnum = {Red, Green, Blue};
>

No `=` between name and `{`.

Enumerator scope is a good question. Clearly we do not want global scope.
Rather, as a declaration immedicately contained by a block or top level, we
want lexical scope for the enum name -- and (I think) for the enumerators'
individual names.

What about enumerator name scope for enum in class, without `static`? I'm
not sure, but precedent says that the enumerator names define prototype
properties.

Expression as well as declaration `enum` form follows class and function
precedent. Expression form requires a reserved identifier (not sym or sum
or whatever), which `enum` has been forever, fortunately.

I agree symbol values by default, with ` = 0` or some other number than 0
after the first enumerator name, looks confusing. Recall the first use-case
in the o.p. was (implicit, should rather be explicit) reflection on the
string value that spells the enumerator name.

/be


>
> // How does it work with classes?
> class MyClass {
>   static myVar = 13; // "Class Fields & Static Properties" which omits
> "let"
>   static enum myEnum = {Red, Green, Blue}; // Now we decided to use "enum"
> while we omitted "let" before
>   // Maybe "Class Fields & Static Properties" should use "let" and "const"?
> }
> ```
>
> Or:
> ```javascript
> let myVar = 13;
> let myEnum = enum {Red, Green, Blue};
>
> // How does it work with classes?
> class MyClass {
>   static myVar = 13; // "Class Fields & Static Properties" which omits
> "let"
>   static myEnum = enum {Red, Green, Blue}; // All fine?
> }
> ```
>
> ---
>
> Do we allow this:
> ```javascript
> let myEnum = enum {Red, Green, Blue};
> myEnum.Red; // 0 or Symbol("Red")
> myEnum[myEnum.Red]; // Can we get "Red" like this?
> ```
>
> If we do, how does this work?
> ```javascript
> let myEnum = enum {Red, Green, Blue};
> myEnum.Alpha = 3;
> myEnum[myEnum.Alpha]; // Who is going to put "Alpha" here? It magically
> happens? Probably not.
> ```
>
> ---
>
> Take `HTMLMediaElement` for an example, which has these:
> - HTMLMediaElement.HAVE_NOTHING  = 0
> - HTMLMediaElement.HAVE_METADATA = 1
> - HTMLMediaElement.HAVE_CURRENT_DATA = 2
> - HTMLMediaElement.HAVE_FUTURE_DATA = 3
> - HTMLMediaElement.HAVE_ENOUGH_DATA = 4
>
> And they can be used like this:
> ```javascript
> if (myVideo.readyState >= HTMLMediaElement.HAVE_METADATA) {
>   goodToGo();
> } else {
>   waitForIt();
> }
> ```
>
> How are we going to achieve the same functionality with "Symbol Enums"?
> Don't use Symbols?
> Make Symbols comparable or use something special like NumberSymbol which
> is comparable like this?
> Don't allow users to do this and have them implement methods like
> `isReadyStateGreaterThan()` or `readyStateToNumber()`?
> ???
>
> AFAIK, enums can do this in other languages:
> ```javascript
> let myEnum = enum {Red = 2, Green, Blue};
> // Green is 3, Blue is 4.
> ```
>
> Maybe we can give the user to pick one:
> ```javascript
> let myEnum = enum {Red, Green, Blue}; // Symbol Enum
> let myEnum = enum {Red = 0, Green, Blue}; // Number Enum
> ```
>
> Looks confusing.
>
> ---
>
> How will a user be able to achieve an `HTMLMediaElement` like result?
> (Making enum'd values properites of the class)
> ```javascript
> class HTMLMediaElement extends HTMLElement {
>   // Like this?
>   static enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/}
>
>   // A "Number Enum" generates an object so use it with something crazy
> like "Class Spread Properties"?
>   static ...enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/} // What?
>
>   // Maybe not supporting anything like above, and forcing users to put
> enums in a property
>   static readyStates = enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/};
> }
> ```
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[kdex]

Yes, I'd favor the `Symbol()` approach a lot. @Andrea: Alternatively 
desugaring `enum` values to `Number` is probably an approach that leads 
back to C/C++'s `#define` (which turns out to be a disastrous idea, at 
least software-engineering-wise), since this has horrendous impacts on 
comparison. Consider this:


```js

const PIXELS = enum {
RED,
GREEN,
BLUE
};
const VEGGIES = enum {
ONION,
TOMATO

};
assert(PIXELS.RED === 0);
assert(VEGGIES.ONION === 0);
// Oops
assert(PIXELS.RED === VEGGIES.ONION);

```

Alternatively choosing `String()` would suffer from the same issue, but 
only clash when two `enum`s share common value identifiers; so 
`Symbol()` really is the only reasonable thing to desugar to.



On 16.12.2015 12:31, Coroutines wrote:

On Wed, Dec 16, 2015 at 3:20 AM, Thomas  wrote:

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

This person gets it. +1  :-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Andrea Giammarchi]

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  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.giammar...@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 < 
>> ljh...@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 < 
>>> mozi...@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@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
>
> ___
> es-discuss mailing 
> listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Thomas]

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

Re: Re: Propose simpler string constant

[Alican Çubukçuoğlu]

How are enums declared?
```javascript
let myVar = 13;
enum myEnum = {Red, Green, Blue};

// How does it work with classes?
class MyClass {
  static myVar = 13; // "Class Fields & Static Properties" which omits "let"
  static enum myEnum = {Red, Green, Blue}; // Now we decided to use "enum"
while we omitted "let" before
  // Maybe "Class Fields & Static Properties" should use "let" and "const"?
}
```

Or:
```javascript
let myVar = 13;
let myEnum = enum {Red, Green, Blue};

// How does it work with classes?
class MyClass {
  static myVar = 13; // "Class Fields & Static Properties" which omits "let"
  static myEnum = enum {Red, Green, Blue}; // All fine?
}
```

---

Do we allow this:
```javascript
let myEnum = enum {Red, Green, Blue};
myEnum.Red; // 0 or Symbol("Red")
myEnum[myEnum.Red]; // Can we get "Red" like this?
```

If we do, how does this work?
```javascript
let myEnum = enum {Red, Green, Blue};
myEnum.Alpha = 3;
myEnum[myEnum.Alpha]; // Who is going to put "Alpha" here? It magically
happens? Probably not.
```

---

Take `HTMLMediaElement` for an example, which has these:
- HTMLMediaElement.HAVE_NOTHING  = 0
- HTMLMediaElement.HAVE_METADATA = 1
- HTMLMediaElement.HAVE_CURRENT_DATA = 2
- HTMLMediaElement.HAVE_FUTURE_DATA = 3
- HTMLMediaElement.HAVE_ENOUGH_DATA = 4

And they can be used like this:
```javascript
if (myVideo.readyState >= HTMLMediaElement.HAVE_METADATA) {
  goodToGo();
} else {
  waitForIt();
}
```

How are we going to achieve the same functionality with "Symbol Enums"?
Don't use Symbols?
Make Symbols comparable or use something special like NumberSymbol which is
comparable like this?
Don't allow users to do this and have them implement methods like
`isReadyStateGreaterThan()` or `readyStateToNumber()`?
???

AFAIK, enums can do this in other languages:
```javascript
let myEnum = enum {Red = 2, Green, Blue};
// Green is 3, Blue is 4.
```

Maybe we can give the user to pick one:
```javascript
let myEnum = enum {Red, Green, Blue}; // Symbol Enum
let myEnum = enum {Red = 0, Green, Blue}; // Number Enum
```

Looks confusing.

---

How will a user be able to achieve an `HTMLMediaElement` like result?
(Making enum'd values properites of the class)
```javascript
class HTMLMediaElement extends HTMLElement {
  // Like this?
  static enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/}

  // A "Number Enum" generates an object so use it with something crazy
like "Class Spread Properties"?
  static ...enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/} // What?

  // Maybe not supporting anything like above, and forcing users to put
enums in a property
  static readyStates = enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/};
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Coroutines]

On Wed, Dec 16, 2015 at 3:20 AM, Thomas  wrote:
> 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

This person gets it. +1  :-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Thomas]

Out of curiosity, is anyone working on a proposal for enum? Given the keyword 
has been reserved for so long, it seems a little strange for a proposal not to 
be floating around - unless I've missed something.

> On 16 Dec 2015, at 10:31 PM, Coroutines  wrote:
> 
>> On Wed, Dec 16, 2015 at 3:20 AM, Thomas  
>> wrote:
>> 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
> 
> This person gets it. +1  :-)
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Propose simpler string constant

[Kip Obenauf]

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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Jordan Harband]

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

Re: Propose simpler string constant

[Brendan Eich]

What's wanted is `enum { APPLE, ORANGE, GRAPE }` instead.

Turns out `enum` was one of four Java-ish future reserved words that IE
actually reserved from the ancient days. So we could use it. Some
half-formed talk of using it to define categorical sum types, and even
value types -- i.e., allowing constructors for the parts of sum, and other
operations a la methods.

/be

On Tue, Dec 15, 2015 at 11:45 AM Jordan Harband  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 
> 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@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Andrea Giammarchi]

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

Re: Propose simpler string constant

[Alexander Jones]

TypeScript has this already, so I'm sure we can learn a thing or two from
their implementation.

On 15 December 2015 at 19:56, Andrea Giammarchi  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  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 
>> 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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Propose simpler string constant

[Jordan Harband]

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

Re: Propose simpler string constant

[kdex]

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 
> 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 > 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
> 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@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss



___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss





___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss