Hi Kevin Thanks for your reply.
1) I think the plugin should enforce, at least with a runtime check/ assertion, that the value for a delegate field is non-null. I would rather receive that exception than an NPE inside a synthetic method. The lazy val trick sounds like a decent approach to publishing the "this" reference. 2) My point about Bar and Foo re: interfaces is that I think if we say Bar implements (or extends) Foo, then we expect Bar must implement all of Foo's methods. If Bar just happens to implement Foo's methods by delegating to a Foo, then it is not a Foo, except when using duck- typing. Most of the cases where I wanted to use this sort of delegation was where I had to implement an interface for which there was already a reasonable implementation I could delegate to. What I'm not sure of is what this would feel like in practice. Presumably Bar could actually implement one or more of Foo's methods even if delegating to Foo. But then the API of Foo is partly implemented by concrete methods on Bar, and partly by synthetic, hidden methods on Bar which delegate to Foo. That would seem non- obvious when reading the source code for Bar. What's your experience so far--do you find this confusing when using your compiler plugin? 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.
