@tig said:
I assumed that if you stop a timer it's the same as ' break' in a block, so then it'd never get to image.erase!, but having tested it I see that it complete the entire iteration after the timer is stopped !
Of course it does. A timer just loops and calls the block on the set interval. (The setInterval timers in Javascript work the same way.)
This why you should always stop the timer immediately when the condition is met. Otherwise the block gets queued up to be executed again, perhaps even before the first time is done doing it's work.
@tig said:
I don't immediately see the advantage of using @tid over tid - the block of code executed by the timer is referring back to itself, ...
Sometimes it works. But I have experienced that in some situations, the ID reference becomes invalid (perhaps gets garbage collected.) And then the call to stop the timer does not work.
[I remember having a discussion with Jim Foltz about timer IDs being invalid, or garbage collected.]
The Ruby docs say a proc is supposed to have access to it's environment (like a snapshot,) when it is defined. But the API UI timer is implemented on the C++ side.
@tig said:
... it's not like we are stopping it in another def method ?
I always assume code samples are going to run in a method.
It is rare that code is something that runs once at startup, (although we sometimes do post code like that.)
THIS feature we are discussing, is something that will be used "on demand" (by a end user,) in a Tool class or a UI::Command, which means it'll likely be wrapped in a method.
Bottom line, ... the above is my best advice on best practice. Believe or not, as you will.
It is not arbitrary. I have had timer use fail in the past when using local var for the id. Perhaps under Ruby 2.0, things have changed with regard to the timer IDs, .. but I still always use a persistent reference for timer IDs on the Ruby side, until I know it is no longer needed.
As far as using rescue in modifier position goes, that is a no brainer. (And is not a best practice rule I made up. I got it from one of the Style Guides or maybe the "Pick-Axe" book.)
begin; statement; rescue; end
is just plain uglier, and doesn't read as nice as:
statement rescue nil