Feature Request: Support binding factory methods to different types with annotation

[jbarr21]

I noticed that in some scopes, I find myself needing to create many class implementations for types with lots of parameters, but I only want to expose their interface type for encapsulation.

Given interface Foo and concrete implementation FooImpl with 5+ constructor parameters, instead of needing to write a Scope like:

abstract FooImpl fooImpl();

@Expose
abstract Foo foo(FooImpl impl);

It'd be cleaner and less verbose when we have a lot of these in our scope to be able to use an annotation to override the type the newly created object is bound to:

@Expose
@BindTo(Foo.class)
abstract FooImpl fooImpl();

This would use the primary constructor in FooImpl to instantiate a new instance, but only add it to the DI graph as if a new instance of Foo was created.

[Leland-Takamine]

Use case makes sense. Discussion from here is whether is warrants a new API. Some questions around this API:

It's confusing whether the @Expose applies to Foo or FooImpl or both. Is there a version of this that is not ambiguous?

[jbarr21]

The @Expose would only expose the type provided by the @BindTo which overrides the type from the factory. Would that maybe be clearer by using private?

@Expose
@BindTo(Foo.class)
private abstract FooImpl fooImpl();

I think max clarity would probably provided by this, but not sure if you want to duplictate the expose semantics in addition to adding this new functionality:

@BindTo(Foo.class, expose=true)
private abstract FooImpl fooImpl();

[andreasnomikos]

I do not agree with this proposal. The drawback of a new api/annotation doesn't justify the small benefit of the syntactic conciseness. We already support aliases through the abstract Foo foo(FooImpl fooImpl) So duplicating the api for the same declaration is highly redundant. For context we also debated this extension at the Facebook Ultralight DI project and reached this conclusion. Also in my view hiding the Impl from the graph can be also supported by a warning at the IDE level and doesn't need to be a core part of the api.

…

On Tue, Jan 21, 2020, 4:46 PM James Barr ***@***.***> wrote: The @expose would only expose the type provided by the @bindto which overrides the type from the factory. Would that maybe be clearer by using private? @***@***.***(Foo.class)private abstract FooImpl fooImpl(); I think max clarity would probably provided by this, but not sure if you want to duplictate the expose semantics in addition to adding this new functionality: @bindto(Foo.class, expose=true)private abstract FooImpl fooImpl(); — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#177?email_source=notifications&email_token=AADH7LOU2DA6EGWNA5SJPPLQ66JODA5CNFSM4KJ5UXG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJR2L5I#issuecomment-576955893>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADH7LOU4QVOOCIEDROAIPDQ66JODANCNFSM4KJ5UXGQ> .