I still think there's a problem there. If you run planChime once and wait, then lets say chimeTimer gets set to the number 2. Now the setTimeout callback is called and the timer is finished, but chimeTimer is still set to 2.
Maybe now some other code calls setTimeout and gets a new timer with ID 2.
Next time you call planChime it'll then disable that new (unrelated) timeout - so I feel like the original code was still better.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I still think there's a problem there. If you run
planChime
once and wait, then lets saychimeTimer
gets set to the number 2. Now the setTimeout callback is called and the timer is finished, butchimeTimer
is still set to 2.Maybe now some other code calls setTimeout and gets a new timer with ID 2.
Next time you call planChime it'll then disable that new (unrelated) timeout - so I feel like the original code was still better.