> On Sat, Dec 21, 2002, Leo Sutic wrote: > > > 1. The resulting delegate class must implement equals() in the same way > > > as the Excalibur delegate. > > > > I've added this. Is it correct that you could have two equal delegates > > that implement different interfaces? > > Hmmm... You know, I didn't think about that. The issue only surfaces when > you have a multi delegate that calls a method in an object through two > interfaces, or when you subclass a delegate interface: [snip] > I'd say yes, it is correct that you could have two equal delegates > that implement different interfaces.
My gut feeling was that different interfaces should result in inequality, but I'm not sure what the use case for comparing two delegates is anyway. Can you give me some? [snip] > Don't get me wrong - having fast delegates is good, and I think that you've > done a great job - but from my point of view, the great things you bring > are not the performance gains, but the organizational. Sure. Although if it does happen that CGLIB gets used by Avalon, there would need to be a good rationale and understanding of the general usefulness of each class that gets moved over. For my benefit, it would be helpful to have a summary of which classes are under consideration, how they fit into the Avalon framework at a macro level, and how they could be useful outside of Avalon. > > > 5. I'm not sure I like the fact that the delegate object also doubles > > > as a factory. You can get method signature collisions. > > > > I've changed the code so that you'll get a ClassCastException if you > > make a newInstance of the wrong type (before it was deferred until you > > invoked the delegate). > > > > The method is used internally to generate new instances from cached > > factory versions of the delegates. It could be made a protected method, > > but I think it can be useful as a public API too (faster than going > > through the cache). I'm not set on this though. > > I'm more worried about method signature collisions that you may get. > Suppose I want a delegate and I define the interface to have a newInstance > method with the exact same parameters as the existing newInstance method. > Protected or public, you will see some strange things happening. > > It exposes an implementation detail (the signature newInstance (...) is > already taken) that doesn't have to be exposed. I understand now. I'll go ahead and make the factory protected, and change the name to something less likely to conflict (for example "cglib_newInstance", which is already used in another class for this same reason). [snip] > This is equivalent to the current proxy class that you generate, but with a > constructor, and without a newInstance method. > > In the cache you keep a mapping between methods and classes of the type > above. Then, when you create a delegate, you see if you have defined a > class for it before (check the cache), and if not, create it. Then you > invoke the single-arg constructor with the target object and return the > instance. > > That separates the factory and delegate roles for the objects and > eliminates the mixing of concerns (factory and proxy). The problem is that invoking the constructor of the generated class would require reflection, which will give back a lot of the performance gains. The only other alternative is to generate yet another class whose sole purpose is to call the constructor of the delegate, but I do not think it is worth it. -Chris -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
