Open GoogleCodeExporter opened 9 years ago
Sorry, this should have been submitted as an enhancement. I don't see a way to
switch the issue type.
Original comment by max.r...@gmail.com
on 18 Mar 2008 at 5:14
My only anxiety about this is it adds another interface to our API. That
interface doesn't do anything and it
encourages users to use instanceof.
As a hack workaround, I believe you can differentiate between enhanced and
standard classes by calling:
boolean isEnhanced = getClass().getName().contains("EnhancedByGuice");
Anybody else have an opinion on this?
Original comment by limpbizkit
on 14 May 2008 at 3:23
Original comment by limpbizkit
on 14 May 2008 at 4:26
Your suggestions is exactly what I'm doing, but it's relying on an internal
implementation detail which you're obviously free to change at any time.
My mistake for trying to dictate the solution rather than just explaining the
problem
I need solved.
One use case is when you have a Map keyed by Class. Maybe you're mapping the
Class
to a processor that knows how to do something with instances of that Class:
Processor getProcessor(Foo foo) {
return processorsByClass.get(foo.getClass());
}
If you're using Guice and a module is setting up interceptors on instances of
Foo and
this method receives a Foo that was created by Guice, the processor lookup will
fail.
I'd be happy with any mechanism that allows me to reliably determine if I'm
dealing
with a dynamically created Guice subclass. So, an interface works, but if
marker
interfaces bother you (and it sounds like they do) then a helper method
(isGuiceEnhanced()) would be just as useful.
Thanks,
Max
Original comment by max.r...@gmail.com
on 14 May 2008 at 4:45
This kind of requirement is quite common in classpath scanning code (though I
think, not the greatest idea in
the world =). One solution would be to do a super-crawl until you detect a
class that's recognized, then cache
the proxy class as a transparent pointer so the next time it's a constant
lookup.
Original comment by dha...@gmail.com
on 31 Jan 2009 at 5:48
Are these objects instances of classes you control (meaning, are they
instantiated by
Guice)? If so, maybe you could create an interface of your own with a method
that
would return the correct TypeLiteral of each object. The technique that Jesse
Wilson
posted on his blog may just do the trick:
http://publicobject.com/2008/11/guice-punches-erasure-in-face.html
Original comment by rco...@gmail.com
on 31 Jan 2009 at 12:46
[deleted comment]
Marking acknowledged pending prioritization.
Original comment by cgruber@google.com
on 16 Jul 2012 at 6:05
I also miss this feature a lot, and I don't see any problem in inserting a new
interface. I'm using Guice now to replace a library internally developed and we
have such a mark interface, called EnhancedClass. We do the following:
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(baseClass);
enhancer.setInterfaces(new Class[]{EnhancedClass.class});
> That interface doesn't do anything and it encourages users to use instanceof.
I don't see any reason to avoid the instanceof operator, could you explain more
on this?
Original comment by bruno.me...@visagio.com
on 22 Nov 2012 at 1:03
One more comment, the workaround should be
boolean isEnhanced = getClass().getName().contains("EnhancerByGuice")
instead of
boolean isEnhanced = getClass().getName().contains("EnhancedByGuice");
At least on Guice 3.0 it is.
Original comment by bruno.me...@visagio.com
on 22 Nov 2012 at 3:24
Original comment by cgruber@google.com
on 18 Nov 2013 at 7:59
Original comment by cgruber@google.com
on 18 Nov 2013 at 8:00
Original issue reported on code.google.com by
max.r...@gmail.com
on 18 Mar 2008 at 4:19