bineanzhou / google-guice

Automatically exported from code.google.com/p/google-guice
Apache License 2.0
0 stars 0 forks source link

All enhanced classes should implement a marker interface #187

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
All enhanced classes should implement a marker interface so that client
code has a reliable way to determine if an object is an instance of a
Guice-enhanced class.  Ideally the interface(s) would be configurable by
the client, but if Guice just has its own interface that its proxies always
implement that would be cool too.

Original issue reported on code.google.com by max.r...@gmail.com on 18 Mar 2008 at 4:19

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by limpbizkit on 14 May 2008 at 4:26

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Marking acknowledged pending prioritization.

Original comment by cgruber@google.com on 16 Jul 2012 at 6:05

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by cgruber@google.com on 18 Nov 2013 at 7:59

GoogleCodeExporter commented 9 years ago

Original comment by cgruber@google.com on 18 Nov 2013 at 8:00