Glad to see someone is working on this. In a Java implementation, I would expect that Bar, which delegates to Foo, would have implemented Foo, so that the clients of Bar would know what methods were available on it, e.g. what contract it fulfilled. In Java, this would be like implementing Comparable then delegating the comparison to a helper class that works via reflection. I believe Lombok takes this approach (saw some slides to that effect at Devoxx); when your class implements an interface, you can have the methods in that interface implemented by another class which you delegate to. I think that's a good practice to follow, as in essence one is saying, "I implement this interface, and it's none of your business how I do it".
I've wanted something like this for a while now, and am glad someone is working on it, but there are two problems I don't see how you can get around: - synthetic methods of this sort cause debugging and stack traces to not match the source file; for example, if the target object (the receiver of the delegation) is null, you will receive an NPE inside synthetic code - I believe you can't safely publish the "this" (e.g. Bar) from inside its constructor, meaning you can't do (in Bar's constructor) foo = new Foo(this); this ends up (in my mind) reducing the usability of the technique. See JCIP, chapter 3, "Sharing Objects", "Safe Construction Practices" In order to avoid the NPE issue, I believe one should enforce that the field is a val, and is assigned a non-null value on construction. Also, as far as terminology, I believe Josh Bloch calls this "forwarding" (see Effective Java, Second Edition, item 16). Regards Patrick -- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en.
