The addition of a createInstance event allows the code using Resque to implement its own instantation methods. My use case was to extract jobs pre-configured with their object dependencies from a DIC.
This event can also handle instances of providing a backward compatible instantiation method if the current instantiation method changes .
fix bug preventing stopListening from working
add createInstance event to allow override of instance creation
method and class existance testing in getInstance()
I'd be more inclined to have my job classes handle that kind of operation, personally. Jobs should be composed of classes designed for that express purpose - being used as a Resque job. The job class can then extract and instantiate/initialize whatever other objects you've stored as the actual work, and can make appropriate calls to ensure that work gets done. This is a far cleaner approach than trying to shoehorn existing classes/objects into the role of a Resque job.
Thanks for chiming in Dan - I definitely agree with your thoughts on this one. Am going to close for now.