Not to hijack this thread, but will this mean increased start-up
performance?
On Friday, September 7, 2012 12:36:34 PM UTC-5, Christian Gruber wrote:
>
> There are different possibilities under discussion. The main problem is
> that we are moving more towards up-front validation and static analysis, so
> the more that can be swapped-in over a default, the trickier some of that
> gets.
>
> On Friday, September 7, 2012 at 10:44 AM, robertdup wrote:
>
> @scl
> I've still not practices with Custom Injection. I will take a look !
>
> @Stuart McCulloch
> This way looks good;even if it's a pity to lose Guice AOP =)
>
> @Fred Faber & @Russ
> I think that I will use this solution...
>
> Thanks you for all your proposition; I appreciate !
> Someday, perhaps, Guice will implement a functionnality to do it more
> easily =)
>
> On Friday, September 7, 2012 4:34:34 PM UTC+2, Russ wrote:
>
> I've done the same thing in my project, taking it a step further: I've
> hidden the annotation implementation in an InvocationHandler and written a
> simple factory that takes the annotation class and enum value and creates a
> dynamic proxy for the annotation desired:
>
> public final class AnnotationFactory {
>
> public static <A extends Annotation,
> E extends Enum<E>> A create(final Class<A> annoClass,
> final E theEnum) {
> // Details omitted for brevity
> }
> }
>
> An AnnotationInvocationHandler class (not shown) implements the details of
> the annotation specification. You wouldn't then be forced to re-implement
> the annotation implementation for each new annotation class you create,
> just create them programatically using the factory.
>
> Your code could then look like this:
>
> private void bindFoo(Class<? extends Foo> fooClass,
> WhatKindOfStuff whatKindOfStuff) {
> bind(Foo.class)
> .annotatedWith(AnnotationFactory.create(DoesFooStuff.class,
> whatKindOfStuff))
> .to(fooClass);
> }
>
> This makes DoesFooStuffImpl class unnecessary.
>
> -Russ
>
> On Fri, Sep 7, 2012 at 9:59 AM, Fred Faber <[email protected]> wrote:
>
> Noticed the typos now. I started by naming "DoesFooStuff" naming as "
> FooClient", so please disregard those references.
>
> On Fri, Sep 7, 2012 at 9:57 AM, Fred Faber <[email protected]> wrote:
>
> A pattern to mitigate the boilerplate is to use a parameterized
> annotation:
>
> @Retention(RetentionPolicy.RUNTIME)
> @BindingAnnotation
> public @interface DoesFooStuff {
> DoesFooStuff value();
>
> enum WhatKindOfStuff {
>
> STUFF_THAT_A_WANTS,
>
> STUFF_THAT_B_WANTS,
>
> ...
>
> STUFF_THAT_Z_WANTS
>
> }
>
> }
>
> You would then use this to annotate your Foos:
>
>
> class AFoo {
>
> @Inject AFoo(@DoesStuffForFoo(Foo.WhatKindOfStuff.STUFF_THAT_A_WANTS) IFoo
> foo) {
>
> ...
>
> }
>
> }
>
>
>
>
> In your module you'd define an implementation of the interface (which is
> tricky...you need to be careful to follow the spec on the Annotation javadoc):
>
>
> @SuppressWarnings("ClassExplicitlyAnnotation")
> private static class DoesFooStuffImpl implements DoesStuffForFoo {
>
> private final WhatKindOfStuff value;
>
> private DoesFooStuffImpl(WhatKindOfStuff value) {
>
> this.value = value;
> }
>
> @Override WhatKindOfStuff String value() {
> return value;
> }
>
> @Override public Class<? extends Annotation> annotationType() {
> return DoesStuffForFoo.class;
> }
>
> @Override public String toString() {
> return "@" + DoesStuffForFoo.class.getName() + "(value=" + value + ")";
>
>
> }
>
> @Override public boolean equals(Object o) {
> return o instanceof DoesStuffForFooImpl
>
> && ((DoesStuffForFoo) o).value().equals(value());
> }
>
> @Override public int hashCode() {
> return (127 * "value".hashCode()) ^ value.hashCode();
> }
>
> }
>
>
> You could then define a helper method as syntatic sugar over the binding:
>
>
> private void bindFoo(Class<? extends Foo> fooClass, WhatKindOfStuff
> whatKindOfStuff {
>
> bind(Foo.class)
> .annotatedWith(new DoesFooStuffImpl(whatKindOfStuff))
> .to(fooClass);
> }
>
> And then your bindings become:
>
> @Override protected void configure() {
> bindFoo(FooThatAFooWants.class, WhatKindOfStuff.STUFF_THAT_A_WANTS);
> bindFoo(FooThatBFooWants.class, WhatKindOfStuff.STUFF_THAT_B_WANTS);
> ...
> bindFoo(FooThatZFooWants.class, WhatKindOfStuff.STUFF_THAT_Z_WANTS);
> }
>
>
> Fred
>
> On Fri, Sep 7, 2012 at 3:02 AM, robertdup <[email protected]> wrote:
>
> Yes it's right.. but this way don't satisfy me totally cause I have some
> XFoo classes.
> I will have to create many annotation (@A,@B, ..., @Z), and I must bind
> all of them or I will get a guice exception.
>
> bind(IFoo.class).annotatedWith.(A.class).to(DefaultFoo.class);
> bind(IFoo.class).annotatedWith.(B.class).to(DefaultFoo.class);
> [...]
> bind(IFoo.class).annotatedWith.(Y.class).to(DefaultFoo.class);
> bind(IFoo.class).annotatedWith.(Z.class).to(DefaultFoo.class);
>
> In my case, I just have to override a couple of binding and let the other
> on the default implementation (DefaultFoo.class)
> bind(IFoo.class).annotatedWith.(E.class).to(MyEFoo.class);
> bind(IFoo.class).annotatedWith.(K.class).to(MyKFoo.class);
>
> Otherwise, PrivateModule looks too "heavy" to implement in my case..
>
>
> - Well, Is there an other way that could be less verbose ?
>
>
> Best regards;
>
>
> On Friday, September 7, 2012 3:59:12 AM UTC+2, Fred Faber wrote:
>
> Strictly speaking, the robot legs problem describes a scenario where the
> types of your object chain are identical. In your case, you wouldn't have
> AFoo and BFoo, but just Foo. It's a luxury of sorts to have AFoo and BFoo
> because you _can_ use a binding annotation on the constructor of each.
> That is the solution I would prefer for its clarity in how AFoo and BFoo
> are being configured:
>
> class AFoo {
> @Inject AFoo(@DoesStuffRelatedToA IFoo ifoo) { ... }
> }
>
> class BFoo {
> @Inject BFoo(@DoesStuffRelatedToB IFoo ifoo) { ... }
> }
>
> Here, grepping through the code directly for DoesStuffRelatedToA would
> lead me to the binding for IFoo in context of AFoo, and that's a little bit
> of a win for code maintenance.
>
> Fred
>
> On Thu, Sep 6, 2012 at 12:51 PM, robertdup <[email protected]> wrote:
>
> Thanks for your reply.
>
> Do you know if it's a common uses to have more than 20 privates modules ?
>
>
>
> On Thursday, September 6, 2012 4:00:35 PM UTC+2, Thomas Broyer wrote:
>
> This is known as the "robot legs" problem, see http://code.google.com/p/**
> g**oogle-guice/wiki/**FrequentlyAsk**edQuestions#How_**do_I_build_**
> two_similar_but_**slightly_**different_trees_of_**objec<http://code.google.com/p/google-guice/wiki/FrequentlyAskedQuestions#How_do_I_build_two_similar_but_slightly_different_trees_of_objec>
>
> On Thursday, September 6, 2012 9:14:24 AM UTC+2, robertdup wrote:
>
> Hello there,
>
> I trying to implement default binding on my module without any success...
>
> Here is what I would like to do (*my dream*) :
>
> class AFoo
> {
> @Inject AFoo( IFoo foo ){}
> }
>
> class BFoo
> {
> @Inject BFoo( IFoo foo ){}
> }
>
>
> bind(IFoo.class).to(**DefaultFoo**.class);
> bind(IFoo.class).to(OtherFoo.**c**lass)*.on(BFoo.class)*;
>
>
>
> I know that I could solve this problem using annotation like this :
>
> class AFoo
> {
> @Inject AFoo( @A IFoo foo ){}
> }
>
> class BFoo
> {
> @Inject BFoo( @B IFoo foo ){}
> }
>
>
> bind(IFoo.class).**annotatedWith**(A.class).to(**DefaultFoo.class)**;
> bind(IFoo.class).**annotatedWith**(B.class).to(**OtherFoo.class);
>
>
> But this way is too boring and dirty.. (because I have to add
> annotation/binding definition for each one)
>
>
> - *Are there some others ways to solve Default binding "problem" ?*
>
> Thanks in advance; Best regards
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To view this discussion on the web visit https://groups.google.com/d/**
> msg/google-guice/-/**bqRh1CKDwsEJ<https://groups.google.com/d/msg/google-guice/-/bqRh1CKDwsEJ>
> .
>
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to google-guice...@**
> googlegroups.com.
>
> For more options, visit this group at http://groups.google.com/**
> group/google-guice?hl=en<http://groups.google.com/group/google-guice?hl=en>
> .
>
>
>
>
> --
> 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.
>
>
>
>
> --
> Gambling Problem? Call 1-800-Gambler
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-guice/-/1JhF9-nY1McJ.
> To post to this group, send email to [email protected]<javascript:>
> .
> To unsubscribe from this group, send email to
> [email protected] <javascript:>.
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-guice/-/DMiQb3afXlYJ.
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.
