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 [email protected] www.isiahmeadows.com On Tue, Jun 12, 2018 at 9:40 AM, kai zhu <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
