Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
thanks
Original comment by gavin.k...@gmail.com
on 24 Jun 2009 at 1:44
Original issue reported on code.google.com by
michael....@gmail.com
on 17 Jun 2009 at 2:25