Reschedule Events 04

Another small step in the development of the reschedule tool and more planning.

Basic methods and inputs

I’ve nailed down the basic methods outlined in my first post and the function chain has changed a little to accommodate for the unavailability of the while method name:

tad_reschedule('my_hook')
    ->until( get_option('my_condition', false) )
    ->each( 600 )
    ->with_args( array( 'one', 'two', 'three') );

Each of the parameters passed to the methods can be also be a callback, beside the obvious type, and while that would cover the initial spec I’m missing something.

Chain tail

The final method closing the chain, the get() method in the case of the WP-TLC-Transients function chain, is missing leaving the class taking charge of rescheduling either in a limbo of not knowing when the chain has ended or doing the same work over and over again on each method call.
First scenario goes like:

  • an instance of the tad_Reschedule class is created
  • method until is called on the class
  • method each is called on the class
  • method with_args is called on the class
  • what happens now? Should the hook be rescheduled?

Second scenario is way more costly:

  • an instance of the tad_Reschedule class is created
  • class reschedules the hook with default condition, default time and no args
  • method until is called on the class
  • previous event is de-scheduled
  • class reschedules the hook with condition, default time and no args
  • method each is called on the class
  • previous event is de-scheduled
  • class reschedules the hook with condition, time and no args
  • method with_args is called on the class
  • previous event is de-scheduled
  • class reschedules the hook with condition, time and args

Adding a chain tail of sort, think of a go() method, would solve it.

Possible solutions

I’m not even taking the second scenario into serious consideration and see some possible roads for further development:

  1. add a chain tail method
  2. act on the class __destruct method: after the last method, whatever it is, the class instance will be available for destruction as not referred by any object
  3. keep a list of called methods and reschedule when all the necessary method (now until, each and with_args) have been called; this would create the need for an argument empty call to with_args()

Next

I will tackle the solution 2 first, if possible I find it classy; this post code is on GitHub.

Probably related

I appreciate your input