Open abatishchev opened 8 years ago
This is an interesting idea. We'll help you review this as time allows, but it might need to wait to review and accept this after our 2.0.0 release, which is our current focus. Feel free to ask us any further questions.
hi @christopheranderson, can we come back to this idea, please?
@abatishchev to address your ask, I think we'd have to spend time looking at our DI story all up, which is pretty bare bones at this point as others have pointed out / complained about. The IJobActivator
interface is only for creating job classes - it isn't a general purpose factory for other types, so I don't think it would make sense here. That's why it doesn't have the Type overload as you pointed to above.
To solve this correctly we'd likely introduce a new mechanism that generalizes and subsumes the old IJobActivator functionality, or we would introduce breaking changes to IJobActivator. This didn't meet the bar for 2.0 - we had to get that release out.
thanks for in insight! I just was hoping that this breaking change suits 2.0 well
@mathewc hi, should we come back to this idea? Or give up and close?
TimerSchedule
creates an instance ofTimerSchedule
usingSystem.Activator()
. And doesn't useIJobActivator
what prevents dependency injection and deferring schedule configuration from compile time to runtime.Theoretically
Create()
could accept an instance ofIJobActivator
but here another problem: it has only methodT CreateInstance<T>()
and doesn't have a non-generic overload such asobject CreateInstance(Type type)
.Is it something you would consider to review if I submit a pull request, please?