2008/10/15 Dhanji R. Prasanna <[EMAIL PROTECTED]>: > On Wed, Oct 15, 2008 at 5:05 PM, James Strachan <[EMAIL PROTECTED]> > wrote: >> >> >> So there's definitely plusses and minuses to this. >> >> Sure adding a new constructor breaks things - but then it would break >> things very fast (in the same way that adding a parameter to a >> constructor might break things too). Folks should run unit test cases >> so catch these breakages pretty quickly. > > Yea but the point is that break is caught at compile time in idiomatic Java, > and doesn't require unit testing.
I don't follow this one - have I missed something? Things would only fail if you had a unit test attempting to bind the class (without a provider method) when creating a Guice injector right? Or is there something else I'm missing? The argument seems to be between 'mandatory' or 'recommended'. e.g. if Guice *recommended* you add an @Inject to single constructors with arguments as good practice (it could even generate a warning if it injected classes without an @Inject annotation) - then folks can choose to follow the recommendation and still have their code break if someone adds another constructor - or folks could still bind any old Java class they find from the zillions of Java libraries out there if they have a single constructor without having to write a provider method for every class/constructor combination. >> On the plus side - think of the zillions of Java classes out there >> that Guice would be able to automatically inject without folks having >> to write their own magic AOP bytecode swizzler, get access to the >> code, hack it and re-release it or write custom providers. > > I can see the merit in this argument. Given that not enforcing @Inject gives lots of benefits to folks using external code and folks who want to can still stick to adding an @Inject everywhere just in case - you can see which side of the fence I sit :). My gut feel is that forcing the addition of an extra mandatory annotation on a perfectly well written Java class before Guice will even consider injecting it seems kinda anti-Java; when folks can use @Inject in the way you'd like (to make things break if folks refactor). It'd be pretty easy to use a compile time tool (e.g. a little annotation processor) to mandate any project's code always uses an @Inject on a constructor within a certain package for those folks who wanna lock down codebases. There's a massive difference between owning an entire codebase and being able to enforce coding styles to aid refactoring - and being easily able to reuse an external library. Maybe make this a flag then? Strict mode is on by default but it can be disabled if folks wanna use code they don't control & wanna avoid writing loads of unnecessary provider methods? -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
