mmerickel
commented
4 years ago I'm a big fan of some form of auto-synthesizing factories, and the dataclass support has been a great start already. My general thinking on this is that it should be a series of synthesizers (factory factories / factory creators) which each get a shot at saying whether they support the supplied object. Probably with the assumption that if the object falls through then it is an error unless it is callable - then it is used directly as a factory.
I would have preferred it be type-based but things like dataclasses and attrs classes cannot be detected by simply an isinstance check. For example attrs.has(obj) or dataclasses.is_dataclass(obj).
I suspect the path forward would be to support a registration mechanism for auto-synthesizers/creators on the ServiceRegistry. Something like registry.register_factory_synthesizer(dataclass_factory_synthesizer). This allows you do then simply call registry.register_factory(some_dataclass, LoginService) and wired will run it through the synthesizer chain to turn it into a factory. It's basically middleware (or a view deriver if you want some precedent in Pyramid) that can wrap the factory.
And of course @factory should be a venusian alias for registry.register_factory.
Putting it all together you'd have something like:
def typed_function_factory_synthesizer(obj):
if inspect.isfunction(obj) and ...:
inject = ... # pull the types out of the signature and hang onto them
def wrapper(container):
# use container.get(...) to grab necessary services, then invoke obj with them
return inject(obj, container)
# return None to let another synthesizer try and wrap it
@factory()
def login_factory(dbsession: Session) -> LoginService:
dbsession = container.get(name='dbsession')
return LoginService(dbsession)There's more middleware-y approaches too if we wanted to cascade / wrap multiple times like passing in (obj, next) into the synthesizer, and having it call next(result). I'm not sure that flexibility is warranted here.
pauleveritt
From a Jan 10 conversation
tl;dr Rewrite and refactor decorator and injector support to support function DI and clarify usage
Generic Decorator
We want a decorator that can register factory functions as well as dataclasses. Along the way, we want clean up naming and allow overriding how this “creator” happens.
Say you have the following:
We’d like, as the explicit case for a decorated registration:
The changes:
registry.register_functionlinefactorygets expanded towired_factoryto make it explicitcreatorcallable into a wired factorycreatorcallable can now handle function-based services instead of just dataclass-based services, through use of specific "creators"Or, a shorthand notation:
In this case:
for_is deduced from the type annotation for the return typecreatoris deduced from the wrapped target…if it is a function, we usewired_function_creatorOf course you can use an imperative form. In fact, we already have one:
registry.register_factory. We could handle the explicit case above:In existing cases, we don’t need a creator. There’s no prep work for the callable. However, if we change to support DI on functions, we’ll want a creator when registering functions.
Here is a shorthand version of this imperative form:
Again, this version:
login_factoryand sees it is a function, thus usescreator=wired_function_creatorlogin_factoryand uses that type as the second argumentThe Calling Pattern
This change makes the two-step dance more explicit.
creatoris a callable that does some work and returns a callable…yes, it is a factory factoryIt also makes the two-step dance extensible. I have wanted a “custom injector”. The injector is, in essence, the factory factory. In this case:
Thus
wired_dataclass_creatoris the “injector”. That is, it returns a callable that, when called, will construct the dataclass instance using DI.If one wanted to customize the injection process, one could make a variation of
wired_dataclass_creator. One could automate/hide usage of it by making a custom decorator.Function DI
Above we discussed:
At first glance this seems unnecessary: the
wired_function_creatorcallable would do nothing more than just returnlogin_factory.But what if we wanted to do DI on functions? For example:
In this case, we do need a factory-factory callable registered as the service.
wired_function_creatorwould look at thelogin_factorysignature and see if it wanted just the container. If so, it would immediately returnlogin_factoryand mimic current behavior.Otherwise, it would presume this function wanted DI. It would return a lambda or function that, during service lookup/construction, would be handed the container and do the DI dance.
This could be simplified in the imperative form:
…and the decorated form:
Extensible Creators
These creator callables are important. They might also be custom. They are a perfect place to experiment with app-specific or site-specific policies (for example, caching.)
In the case of explicitly naming the creator to use, in the decorator or imperative form, this is already handled. Call the creator you want in that case.
Or is it? Perhaps you want a general case for the creator, but have some context-specific cases as exception. For this, one should treat “creator” as itself a service:
With this,
WiredFunctionCreatoris a service in the registry which will return the correct creator for this situation. You then have access to wired’s extension/customization/overriding patterns:This would mean wired would need to “scan” for creators before doing a scan for factories. We could make easier by having a basic registry usage, where this was done all in one step, or a more-advanced two-step process of setting up a registry.
Injector Service
With the above, injection is part of the
creatorstep. Albeit a big, hairy part. People might want a custom creator, but not touch the injector. Or vice versa. People might want a different injector for a specific service.Thus, behind the scenes,
creator=WiredFunctionCreatorwill lookup aWiredFunctionInjectorwhen it wants to do the injection part. The context will thefor_the creator is being used to construct.Along the way, the current injector will be refactored to make each lookup more granular, to make it easier to write your own injector by re-using pieces of the existing injector. It will also be easier to test (all lookups are currently inlined in a big for loop.)