Question: mapping of pin-state values

[troywweber7]

Will firmata's board.LOW always map to 0 and board.HIGH always map to 1?

If not, that explains why it exists as a constant on the board itself. If so, however, I would suggest it be exported as a separate constant. Something like (pardon my ES6 syntax):

const PIN_STATE = {
    ON:1,
    OFF:0,
    HIGH:1,
    LOW:0
}

I ask because I'm using TypeScript and I've adapted a Firmata.d.ts definition file to use in my project and my coworker wants to treat this situation as an enum, but I'm nervous about the possibility of some other board I don't know about switching these values at some point. Any insight is appreciated.

[rwaldron]

These would never be anything but:

HIGH = 1
LOW = 0

... But I wouldn't conflate those with "on" and "off" as you have. Consider cathod vs. anode:

The signals will be inverted, so: on = LOW and off = HIGH.

But back to the properties: there is no particular reason or benefit for them to exist on the instance, that's just how this was written back in 2011; now it amounts to a legacy design that remains in place to prevent breaking existing code. There's nothing particularly compelling about redefining them as class-side static properties, either. That would be a breaking change for no real benefit. We could define them as class-side properties and deprecate the instance properties (ie. redefine them in terms of descriptors that log a warning when accessed), but that might be too much nannying.

[troywweber7]

First of all, thank you for easing my concern. And for suggesting that ON/OFF not be set in stone.

It may be too much nannying, but my suggestion for the future of firmata.js in regards to this situation would be to:

1. Store instance constants/constant-objects as actual constants (instead of static-class-constants) to encourage people to move in that direction and not accidentally edit their meaning (this would work well with TypeScripts way of importing, as well, because you can do import { SOME_CONSTANT, SomeClass } from 'SomeModule' in TS
2. But also continue to tack on the constants to the instances themselves to support legacy code, or as you say, log a warning

Perhaps I'll take a stab at step (1) myself in the future. But feel free to close this if you feel appropriate because my question was answered. And thank you for that!