Adding support for enums

[Isiah Meadows]

Just wanted to clarify one thing: I did not state they were *superior*
in any explicit sense. I just stated they're *equal*, which is
different. If it were in fact superior, this proposal would've been
much more easily dismissed. But them being equal is why I was asking
"why have yet another way of expressing the same concept?".

Oh, and also, my particular use case for enum-like constructs involves
numeric constants, and when you're dealing with performance-sensitive
protocols, you'll 1. need to care about data size (which pushes JSON
to its limits), and 2. worry about the message size and
deserialization speed of the messages themselves. Peter and I have
pretty similar use cases and constraints (not identical), and I can
tell you that having highly flexible, easy-to-alter (due to frequently
changing requirements or third-party protocols) code is not very high
on either of our lists.

In addition, when you're dealing with that kind of code, string
comparison is *dog* slow compared to integers - it's literally faster
to concatenate two strings (complete with allocation) than it is to
compare two strings of equal length greater than just a few
characters. This only gets worse in embedded, where computational
resources are much more limited, and Moddable (based on my awareness
of their problem domain) has to care a *lot* about resource usage,
even more than mobile developers. If this says anything, they even
wrote their own JS engine to satisfy their unique device constraints.

One final thing: config makes no sense for actual logic, and most
network code that isn't application-level is 99% logic, 1% actual
configuration that isn't by the user itself. Take a look at pretty
much any networking library out there (like ecstatic), and you'll
notice this very quickly, even for the seemingly simple stuff. Fun
fact: caching is non-trivial, fault tolerance is far from obvious, and
directory listings can get pretty intricate. And I didn't even get to
the security or performance aspects of this here, and this is all
written from the assumption that it's only one thread here, since
JavaScript has no explicit facilities for multithreaded code
currently. (This is where things get complicated *quick*.)

-----

Isiah Meadows
me at isiahmeadows.com
www.isiahmeadows.com


On Tue, Jun 12, 2018 at 9:40 AM, kai zhu <kaizhu256 at gmail.com> wrote:
> hi @peter, appreciate your perspective for embedded-device use-case.
> however, as @isiah mentions, there are existing javascript
> design-patterns using dicts/lists that are superior to enums.  the
> primary reason (which was implied) is because they can be easily
> stored/shared/parsed as json config-settings, e.g.:
>
> ```json
> {
>     "DEVICE_LIST": [
>         {
>             "TYPE": "ARDUINO",
>             "ADFlag": {
>                 "LE_LIMITED_DISCOVERABLE_MODE": 1,
>                 "LE_GENERAL_DISCOVERABLE_MODE": 2,
>                 "LE_GENERAL_DISCOVERABLE_MODE_ARDUINO": 3,
>                 "NO_BR_EDR": 4
>             },
>             "ADType": {
>                 "INCOMPLETE_UUID16_LIST": 2,
>                 "COMPLETE_UUID16_LIST": 3,
>                 "INCOMPLETE_UUID128_LIST": 6,
>                 "COMPLETE_UUID128_LIST": 7
>             }
>         },
>         {
>             "TYPE": "RASPBERRY_PI",
>             "ADFlag": {
>                 "LE_LIMITED_DISCOVERABLE_MODE": 1,
>                 "LE_GENERAL_DISCOVERABLE_MODE": 2,
>                 "NO_BR_EDR": 4
>             },
>             "ADType": {
>                 "INCOMPLETE_UUID16_LIST": 2,
>                 "COMPLETE_UUID16_LIST": 3,
>                 "INCOMPLETE_UUID128_LIST": 6,
>                 "COMPLETE_UUID128_LIST": 7
>             }
>         }
>     ]
> }
> ```
>
> you can also save/update these configs to a github-repo (with
> encryption like this real-world example [1]), and perhaps have your
> iot device poll it every 5 minutes for effortless config-updates in
> near-realtime.
>
> -kai
>
> [1] encrypted travis-ci-config-settings hosted on github
> https://github.com/kaizhu256/node-utility2/blob/gh-pages/CRYPTO_AES_SH_ENCRYPTED_kaizhu256