Feature request: dynamic software timers

[djphoenix]

Missing feature

Now we have 7 (0-6) timer control functions. When we need more, we stuck in refactoring.

API proposal

local timer = tmr.create( function(t) -- self in callback
  print("TICK")
  -- after return, deallocated if not repeat nor rearmed
end )
timer:arm(1000, true) -- delay, [repeat=false]
timer:arm_us(152342) -- delay_us, [repeat=false]
timer:disarm()
timer = nil -- deallocated if not armed, kept otherwise

Implementation proposal

I have finished it in my local repo (on top of ETSTimer of course), if there is no rejections of idea, I'll cleanup code, write docs and make PR.

[devsaurus]

@djphoenix Similar ideas were discussed in #709 but there was never a conclusion on how to continue. Personally, I clearly favour an object-oriented solution like yours. Though with the current API in mind, how about the following approach for backwards compatiblity.

As you sketched above, tmr.create() creates a new timer object. It implements the existing tmr methods alarm(), interval(), register(), start(), state(), stop(), unregister() to keep its use model aligned with the existing timers. Non-timer functions are out of scope: tmr.delay(), tmr.now(), tmr.softwd(), tmr.softwd(), tmr.time(), tmr.wdclr().

Much of the existing C code for the functions can be re-used / shared if they are augmented to accept a self userdata object in parallel to the numeric id. This allows to call them in any of these variants:

local mytimer = tmr.create()

-- oo calling
mytimer:register(5000, tmr.ALARM_SINGLE, function (t) print("expired"); t:unregister() end)
mytimer:start()

-- with self parameter
tmr.register(mytimer, 5000, tmr.ALARM_SINGLE, function (t) print("expired"); tmr.unregister(t) end)
tmr.start(mytimer)

-- still using an old timer
tmr.register(1, 5000, tmr.ALARM_SINGLE, function (t) print("expired"); tmr.unregister(t) end)
tmr.start(1)

Does this sound meaningful?

[djphoenix]

Yep, this is good compromise. Let's try it in real world.

[marcelstoer]

👍 for backwards compatibility. However, I'd like to see the old style functions tagged with a deprecation note both in code and the docs. That'll allow us to remove them maybe half a year later.