I am beginning to think that maybe you should bite the bullet and
only require @Inject if multiple constructors are present. Yes, this
would mean that adding a new constructor might break existing code but:
1) It feels like a better default. One of the great things about JPA is
that is comes with great defaults out-of-the-box. It doesn't force you
to annotate fields when it can guess what you'd want it to do. If you
don't like the default you can always override it by adding an explicit
annotation. Why doesn't the same line of reasoning follow for Guice?
2) It will allow Guice to inject classes that cannot be modified, such
as 3rd-party libraries we do not have the source-code for. Having said
that, I'm not sure how practically useful this is.
On the flip side, if you require @Inject why not go the extra step
of requiring developers to provide an explicit constructor with a
@Inject annotation? The current behavior "breaks compatibility" when a
user introduces a custom constructor for the first time. In that sense,
it really isn't much better than moving from one custom constructor to
two...
Gili
Bob Lee wrote:
> On Tue, Oct 14, 2008 at 2:30 PM, Gili Tzabari <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> What about no-arg constructors?
>
>
> Ideally, we'd allow only default public no-arg constructors, because
> there's nothing to annotate and adding an explicit constructor is
> already equivalent to deleting the implicit no-arg constructor, but we
> may end up being a little more permissive to maintain compatibility w/
> 1.0.
>
> Bob
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
