Must an injected method return void?

[GoogleCodeExporter]

An argument can be made that the method should be able to return anything, 
and the result would just be ignored when injected. On the other hand, 
throwing away a result is a little bit weird (although I can't think of 
any possible use that it could be to the injector). 

It might come down to: Is it reasonable to have an injection method double 
as a business method, and is this a use case that is really necessary to 
cover? The question might be asked another way: If it is rare that the 
injection method logic is also useful in business logic that returns a 
result, would it be unreasonable to expect a user to have to declare a 
separate method for injection in that case?

Original issue reported on code.google.com by michael....@gmail.com on 17 Jun 2009 at 2:25

[GoogleCodeExporter]

The specific usecase I'm thinking of is fluent APIs that return this from 
setter-ish
methods. i.e. if I have an API like:

Foo foo = new Foo().setBar(bar).setBaz(baz);

I don't see why setBar() and setBaz() should be prohibited from being injector 
methods.

Original comment by gavin.k...@gmail.com on 17 Jun 2009 at 4:32

[GoogleCodeExporter]

Ah. So, it is the method cascading feature that you want to retain. 

I guess I agree that methods should not be constrained to return void, then.

Original comment by michael....@gmail.com on 17 Jun 2009 at 4:52

[GoogleCodeExporter]

Spring MVC* allows for methods to be injected into that return non-void.  They 
are bound to URLs of course 
and are the bread and butter of its capability.  The arg list is quite open, 
and strongly-typed, typed/named annotated params can be satisfied by Spring, 
including components not necessarily tied to the request or 
model per se.

In summary, injection needs to be capable for non-void methods.  Spring does 
not need an @Inject above 
them though, as this is a secondary** phase to component dependency 
satisfaction (nee 'assembly' and 
'config' from IoC terminology).

Thus - don't worry about whether @Inject implies void-return or not; the 
containers that need it will continue 
to function without @Inject decorating such methods.

* and others

** For PicoContainer, we call this reinjection, as its a non-setup secondary 
phase.

Original comment by PaulHamm...@gmail.com on 17 Jun 2009 at 11:38

[GoogleCodeExporter]

Requiring void does seem unnecessarily restrictive. Guice doesn't check the 
return
type, and I don't recall this ever causing a user pain. As of r4
(http://code.google.com/p/atinject/source/detail?r=4), we now allow any result 
type.

Original comment by crazybob...@gmail.com on 23 Jun 2009 at 11:25

• Changed state: Fixed

[GoogleCodeExporter]

thanks

Original comment by gavin.k...@gmail.com on 24 Jun 2009 at 1:44