setInterval() Bug about taskscheduler HOT 3 CLOSED

Hi Hannes,
That's a good point.Originally, I had tasks automatically disable after last iteration. I should have kept it that way...
setIterations is just a setter method and should not control the execution logic. Next thing you know we will need a setIterationsDelayed() method if immediate execution is not needed.
Maybe I should just go back to that option: it is clean, takes less code and gives programmer explicit responsibility to reactivate the task if s/he so desires... What do you think?
So proposal is to go back to:void Task::setIterations(long aIterations) {
iSetIterations = iIterations = aIterations;
}Drop disableOnLastIteration method altogether, and have the tasks auto-disable after last iteration always.
What do you think?
Anatoli

from taskscheduler.

Fixed in the latest push in the master branch.
I will create a separate branch for a version which always disables task on last iteration

from taskscheduler.

Hi Anatoli,
Hmmmmmmmm, this is a question of design, what you expect from your tool.
I think you have the power and decide the direction where this should go. I don't think that a branch would be a good Idea. Makes it too complicated to decide and therefore less attractive (I think).

Actually Me as a user, I could perfectly live with the variant that a finished Task is disabled automatically. Particularly because you introduced the restart() methods. Since those exist, the cases where you have to change the iterations are quite special cases that do not happen too often.

The only important thing is, that the documentation is consistent with the functionality of the code and that the promised functionality runs flawlessly.

Further more, if it saves some Bytes, go for it!
Hannes

PS.: the good documentation was one of the reasos why I started to work with your library formerly.

from taskscheduler.