• The setWatch is absolutely clear... at least to me... that's why I said I'm a bit embarrassed not to look through all the provided functions before venturing into my own implementation.

    Regarding 'Basically': this became clear to me when some release notes mentioned, that the event buffer size was increased from 64 to 128. Before my work life, I was more a hardware mind - tinkering with germanium transistor OC72... (a black painted glass housing filled with transparent heat conducting paste) and I still love hardware, because you can touch it and you actually can 'see' when something goes wrong (...the heat conducting past developed bubbles... another kind of interrupt). Back to the interrupts we are talking about here: When starting to work with micro processors - Zilog Z8 - to build an in-cable protocol converter - interrupt serving time mattered for timing - and still does, just in a different way. Explaining the setWatch to myself would read like this:

    Set watch registers a JS function with the particular pin. Depending on the raise or falling or both, the core - or basic 'operating system' puts the JS function into a first-in-first-out (FIFO) buffer, from which the JS interpreter later pulls it and invokes it.

    Putting the registered function into a FIFO is - time wise - predictable and defines the rate of how many interrupts can be noticed until getting lost, and the FIFO idea assumes that over time all interrupts can be served, because interrupts come not continuously and therefore the serving can be queued. This may though have ramifications for the interrupt service routine (function) implementation with time dependencies, because with the deferred execution 'things' may already have changed again and have to be newly interrogated to make the proper decision. Catching key strokes have a different dependencies, and in order to handle time sensitive sequences, the time of the even is recorded in the FOFO as well.

    Above 'definition' raises several questions: can a pin have multiple watches set? For the sake of simplicity and basic usage I assume not... that's why I use the pub(lish)/sub(scribe) mechanism which allows me to register with one single setWatch the pub, which in its turn reaches any number of subscribers. Another question is: How can I check 'how full' the FIFO is in order to, for example, tell the user 'to slow down' his activities?

    .itr() does about the same as .forEach() within a few 'nuances':

    1. is not object-oriented - to take a 'bad' part head on
    2. performance is of course way inferior to .forEach() - an other drawback
    3. accepts a start index - helpful for an array that has some meta data about itself in the first (few) element(s), because length is not enough, and to make a new subclass is an overkill.
    4. the index of the element processed is passed to the callback function,... because it may be of interest - same as array may be passed for both, .itr() and .forEach(). With .forEach() getting to the index of the element in the callback function amounts to effort of the order of O2. If accomplishable 'natively'/in the interpreter. It would actually be interesting to look a comparison. On the other hand, I'm sure you - Gordon - have a good guts feeling top of your head, which one would win.

    Regarding, for example, "SLS" for S(hort)L(ong)S(hort) versus ".-.", was intentional: SLS can be use to directly address a method/function within an object, and furthermore, allows the dot (.) notation for topic paths in pub/sub. Btw, there is already code on the web that uses the ".-." notation for morse-texting:
    https://github.com/espruino/EspruinoDocsĀ­/blob/master/tutorials/Morse Code Texting.md, and another one that describes a lock coded using more codes: http://www.espruino.com/Single Button Combination Lock.


Avatar for allObjects @allObjects started