On Nov 24, 10:40 am, Patrick Wright <[email protected]> wrote: > 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.
The problem is that I can't do both together, as soon as I reference a variable to test for null then if it's lazy it has to be initialized at that point, which is still in the constructor... You'll also find that null references are MUCH less common in Scala than in Java, thanks to the Option class: http://www.scala-lang.org/docu/files/api/scala/Option.html http://blog.danielwellman.com/2008/03/using-scalas-op.html http://www.artima.com/forums/flat.jsp?forum=276&thread=203082 > 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. Agreed, if the object that I'm proxying has interfaces, then I'll proxy them as well. Proxying traits really does help here as the compiler has already provided the necessary interface. But I'm still going to have the plugin make a best effort to do something useful, even if when interfaces aren't available. > 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. Exactly, a synthetic method is only generated if a method of the same name and signature doesn't already exist. > 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. It's pretty similar to working with the static mixins and self-types that already exist in Scala, where a constructed object can be pulling in implementations from multiple places. The difficulty in reading code is not really any harder than working with traits. I'm also including sensible position data in the synthesised methods, so that if something does go wrong then the debugger will point to the @proxy as the location of the error. On the other hand, the reduction in boilerplate code only serves to make code more readable, and the synthesized methods are very trivial so there's no real guess work involved. > What's your experience so far--do you find this confusing when using > your compiler plugin? Actually, I'm finding the opposite, things are being simplified and I'm sure that if some of the compiler source I'm working with had used this technique then I would have come to understand it faster. The annotation very clearly reflects my intent as a programmer, something which isn't always immediately obvious when reading long stretches of source code. > 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.
