undefined handling for pin specifier

[phoddie]

Pin Specifiers are passed to IO constructors:

new Digital({pin: 1, mode: Digital.Input});

During development of ECMA-419 2nd Edition, it was observed that when the pin is undefined -- often because the user accidentally left out the pin property -- that pin 0 was used. This is because undefined becomes 0 when coerced to a number. Using pin 0 is entirely unexpected.

The Moddable SDK implementation of ECMA-419 IO was updated to throw on a value of undefined for a pin specifier. This is not currently reflected in the specification. I think we should update this for 3rd Edition.

There are likely other cases where undefined should be rejected as a value, such as Port Specifiers and mode.

[dtex]

I believe there are some boards that address IO's by type only. For example, there may be only two pins available for a microcontroller's Serial or I2C, so the manufacturer will gloss over pin specifiers and just have a serial or i2c class that does not require pins or a port to be specified. Requiring a specifier in 419 would either make those boards non-conformant or force the manufacturer to do something artificial.

The boards I can think of off the top of my head are not boards that could host a JS runtime, but I can imagine a highly configured ESP32 or 8266 in a "no-solder" learning kit where the pin roles are prescribed by the PCB.

[phoddie]

Right. Sometimes there is no pin number at all. The single analog input pin on ESP8266 is an example of that. (And serial and SPI on ESP8266 are also not really configurable beyond a Port Specifier, though they do happen to also have PIN numbers because they can also be used as a GPIO).

I didn't intend this to require a Pin Specifier. The case I'm thinking about is when a Pin Specifier is already required (e.g. ESP32 Digital requires one). In that case, undefined should be rejected rather than coerced to 0.