I'm not a purely front-end developer - I do full stack, and my comfort zone is with Node.js. (My current work is really a giant CRUD app in Rails with some extra data-driven features, so my JS stuff is purely for personal use.) Keep in mind, I use integer enums a *lot* myself, since I also find myself writing a lot of low-level code nowadays. (When performance becomes critical, you have to track any and every allocation you make, so integer enums are infinitely useful.) I don't do a lot of embedded/IoT work, though, so I can't speak for your experience there.
As for your thing, the auto-counter is nice, although it's easily implemented in userland and when managing bit masks, I find it more useful to track the raw value directly rather than to allow the value to be inferred (it's easier to read and easier to maintain). The rest is basically just trading one set of boilerplate for another, and I'm not convinced of its value. I find the `Object.freeze` variant perfectly acceptable, but I've lately just started using raw constants like `const FlagFoo = ...` and similar, since they allow enum dependencies, while remaining fairly static. The only missing piece here is for UglifyJS to start evaluating and inlining constant variables set to literals by default, which would make them equally zero-cost to TypeScript's `const enum`s (which I almost exclusively use in practice). ----- Isiah Meadows m...@isiahmeadows.com www.isiahmeadows.com On Mon, Jun 11, 2018 at 7:20 PM, Peter Hoddie <pe...@hoddie.net> wrote: > I'm not convinced we actually *need* enums in JS. > > > I'm not in a position comment on the need for enums on the web. However, > JavaScript is used beyond the web. We use JavaScript on embedded devices to > implement device drivers and network protocol handlers where having enums in > the language would welcome. Without them, we end up with "code" like you can > see here for BLE: > > https://github.com/Moddable-OpenSource/moddable/blob/df692dd517409616c96d39465816ccfd722144c7/modules/network/ble/gap.js#L41 > > The proposal Ron Buckton presented at TC-39 is nice for simple integer > enums. This... > > let ADType = Object.freeze({ > INCOMPLETE_UUID16_LIST: 0x02, > COMPLETE_UUID16_LIST: 0x03, > INCOMPLETE_UUID128_LIST: 0x06, > COMPLETE_UUID128_LIST: 0x07, > ... > }); > > ..becomes... > > enum ADType { > INCOMPLETE_UUID16_LIST = 0x02, > COMPLETE_UUID16_LIST, > INCOMPLETE_UUID128_LIST = 0x06, > COMPLETE_UUID128_LIST > .. > } > > And bitfields are contemplated, so that this... > > let ADFlag = Object.freeze({ > LE_LIMITED_DISCOVERABLE_MODE: 0x01, > LE_GENERAL_DISCOVERABLE_MODE: 0x02, > NO_BR_EDR: 0x04, > ... > }); > > ...becomes... > > @Enum.flags > enum ADFlag { > LE_LIMITED_DISCOVERABLE_MODE = 1 > LE_GENERAL_DISCOVERABLE_MODE, > NO_BR_EDR, > ... > > } > > > These are welcome improvements. Whether the overall benefits of enum across > the range of situations JavaScript is applied to make it worth adding enums > to the language is now open for discussion thanks to Ron's proposal. > > -- Peter > > > On Jun 11, 2018, at 3:41 PM, Isiah Meadows <isiahmead...@gmail.com> wrote: > > This was the kind of library helper I was alluding to in my email. It's > incredibly easy to introduce a zero-overhead library solution to this > problem. > > To be quite honest, I'm not convinced we actually *need* enums in JS. I've > used design patterns enough that it in my experience is much more flexible > than enums, while in the degenerate case of enums, doesn't actually add any > lines of code, and it doesn't really decrease boilerplate on the user side. > Also, enums aren't common enough in idiomatic JS to really be useful - we > can technically use just about anything to discriminate types on, and our > dynamic typing avoids most of the issues that make things like sum types and > sealed/abstract classes pervasive in other languages. > > ----- > > Isiah Meadows > m...@isiahmeadows.com > www.isiahmeadows.com > > On Mon, Jun 11, 2018 at 4:49 AM, Andrea Giammarchi > <andrea.giammar...@gmail.com> wrote: >> >> it seems to be trivial enough to implement in user-land though >> >> ```js >> class Enum { >> constructor(...names) { >> [].concat(...names).forEach(name => { >> this[name] = Symbol(name); >> }); >> Object.freeze(this); >> } >> } >> ``` >> >> then you can have: >> >> ```js >> const Actions = new Enum( >> 'LOADING_SPINNER', >> 'LOADING_SEARCH_RESULT' >> ); >> ``` >> >> or using an Array if you prefer, with eventually the ability to use an >> object to map keys to values, instead of using symbols. >> >> >> On Mon, Jun 11, 2018 at 9:37 AM, kai zhu <kaizhu...@gmail.com> wrote: >>> >>> hi nicolo, reading-up https://github.com/rbuckton/proposal-enum, i'm >>> guessing this would be the enum-solution to doug's name-collision problem? >>> >>> ```js >>> /* >>> * enum-solution with action = { type: Actions.LOADING_SPINNER, ... } >>> */ >>> enum Actions { >>> LOADING_SPINNER, >>> LOADING_SEARCH_RESULT >>> } >>> ... >>> switch (action.type) { >>> case Actions.LOADING_SPINNER: >>> ... >>> break; >>> case Actions.LOADING_SEARCH_RESULT: >>> ... >>> break; >>> } >>> ``` >>> >>> the above may look nice and familiar to backend-java-developers, but for >>> javascript-frontend-developers trying to manage integration-level >>> complexity, it looks like needless extra-overhead when simpler, throwaway >>> glue-code would likely suffice: >>> >>> ```js >>> /* >>> * plain-string solution with action = { type: 'LOADING_SPINNER', … } >>> */ >>> switch (action.type) { >>> case 'LOADING_SPINNER': >>> ... >>> break; >>> case 'LOADING_SEARCH_RESULT': >>> ... >>> break; >>> } >>> ``` >>> >>> kai zhu >>> kaizhu...@gmail.com >>> >>> >>> >>> On 11 Jun 2018, at 3:50 AM, Nicolò Ribaudo <nicolo.riba...@gmail.com> >>> wrote: >>> >>> Have you seen https://github.com/rbuckton/proposal-enum? The champion is >>> a TypeScript member, so he already had experienc with enums. >>> >>> On Sun, Jun 10, 2018 at 5:44 PM kai zhu <kaizhu...@gmail.com> wrote: >>>> >>>> In Redux, there are actions, which are strings, that get passed to a >>>> reducer, which mutates the states. My coworker and I inadvertently added >>>> the same action name, "LOADING" on the same page, but in two different >>>> files. This led to a bug when both my modal and his search results would >>>> be >>>> loading at the same time, but since they were never both visible, we didn't >>>> catch the bug. >>>> >>>> >>>> can you explain in code how either enum or symbols could solve your >>>> problem? reading up on how reducers work @ >>>> https://redux.js.org/basics/reducers#handling-more-actions, i'm guessing >>>> the >>>> problematic code looks like the following. >>>> >>>> ```js >>>> // module spinner.js >>>> var action = { >>>> type: 'LOADING', >>>> ... >>>> }; >>>> >>>> // module search.js >>>> var action = { >>>> type: 'LOADING', >>>> ... >>>> }; >>>> >>>> // module main.js >>>> switch (action.type) { >>>> case 'LOADING': >>>> // inadverdently run both >>>> // spinner-loading and >>>> // search-result-loading actions >>>> ... >>>> break; >>>> } >>>> ``` >>>> >>>> its not obvious to me how enums/symbols could be use in a >>>> less-complicated solution, than simply renaming action.type in your case >>>> with more descriptive names that won’t collide (e.g. 'LOADING_SPINNER', >>>> ‘LOADING_SEARCH_RESULT'). >>>> >>>> kai zhu >>>> kaizhu...@gmail.com >>>> >>>> >>>> >>>> On 10 Jun 2018, at 11:26 AM, Michael J. Ryan <track...@gmail.com> wrote: >>>> >>>> Just use symbols for your action type >>>> >>>> On Sat, Jun 9, 2018, 14:21 Doug Wade <douglas.b.w...@gmail.com> wrote: >>>>> >>>>> Hello friends! >>>>> >>>>> I had a bug the other day on my team. We use redux to manage the state >>>>> on our application, which is maintained by a large team. In Redux, there >>>>> are actions, which are strings, that get passed to a reducer, which >>>>> mutates >>>>> the states. My coworker and I inadvertently added the same action name, >>>>> "LOADING" on the same page, but in two different files. This led to a bug >>>>> when both my modal and his search results would be loading at the same >>>>> time, >>>>> but since they were never both visible, we didn't catch the bug. My >>>>> coworker refactored his feature, and broke my feature, such that rather >>>>> than >>>>> displaying a spinner, we went straight to an empty results page, even when >>>>> there were results. >>>>> >>>>> In other languages, like the language I use most at work, Java, we >>>>> would instead use a language construct called an enum in this situation so >>>>> that the two different sets of actions weren't equal to each other. I did >>>>> some research into some previous discussions on this topic, and it seems >>>>> like the discussion has been broadly in favor of it. I also noted that >>>>> enum >>>>> is a reserved keyword, which indicates some intention to add enums to the >>>>> language. >>>>> >>>>> As such, I've spent some time working on a proposal for adding enums to >>>>> ECMAScript. It is very heavily based on the work by rauschma, stevekinney >>>>> and rwaldron. I wasn't sure if I was using all the right words when >>>>> writing >>>>> the proposal, so to help express myself better, I also spent some time >>>>> writing a babel plugin that uses a polyfill against which I've written a >>>>> small test suite (if you would like to run them, you'll need to link the >>>>> polyfill and the babel plugin into the tests). Please do not take these as >>>>> any indication of "done-ness", I wrote them to understand how I would >>>>> expect >>>>> an enum in javascript to behave, and am willing and eager to make changes >>>>> as >>>>> I get suggestions. I do, however, feel I have done as much as I can on my >>>>> own, and would like help in considering the proposal, especially whether >>>>> it >>>>> contains any footguns, undefined behavior, or things that would be >>>>> surprising to newer developers, and helping me identify what work is to be >>>>> done to make this a "real" proposal. >>>>> >>>>> All the best, >>>>> Doug Wade > > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
