You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
The current implementation of the Scheduler class requires checking the type of each job (either SimpleIntervalJob or CronJob) to determine which add method to call. This design necessitates additional boilerplate code and type handling on the client's side.
Suggested Improvement:
I propose adding a unified method, addJob, to the Scheduler class to handle the addition of jobs regardless of their type. This method would internally check the job type and delegate to the appropriate existing method (addSimpleIntervalJob or addCronJob).
Benefits:
This change would simplify the Scheduler's usage by abstracting away the need for explicit type checks in client code, making the API cleaner and easier to use.
Request:
I would like to be assigned to this issue to implement the proposed feature, as I have already identified the necessary changes and am prepared to contribute the enhancement.
The text was updated successfully, but these errors were encountered:
Alright!
Do you want me to leave the previous methods such as: addIntervalJob(), addLongIntervalJob(), addSimpleIntervalJob(), addCronJob() public and still usable or make them private and rewrite the tests for new addJob()?
Description:
The current implementation of the Scheduler class requires checking the type of each job (either SimpleIntervalJob or CronJob) to determine which add method to call. This design necessitates additional boilerplate code and type handling on the client's side.
Suggested Improvement:
I propose adding a unified method, addJob, to the Scheduler class to handle the addition of jobs regardless of their type. This method would internally check the job type and delegate to the appropriate existing method (addSimpleIntervalJob or addCronJob).
Benefits:
This change would simplify the Scheduler's usage by abstracting away the need for explicit type checks in client code, making the API cleaner and easier to use.
Request:
I would like to be assigned to this issue to implement the proposed feature, as I have already identified the necessary changes and am prepared to contribute the enhancement.
The text was updated successfully, but these errors were encountered: