On Nov 24, 10:16 am, Kevin Wright <kevin.lee.wri...@o2.co.uk> wrote: > I'll try and answer all the points in one mail :) > > The source is here:http://github.com/scala-incubator/autoproxy-plugin > And the wiki here:http://wiki.github.com/scala-incubator/autoproxy-plugin > The tabs at the top of the page should help you... > > I did also consider @forward in addition to @with, @delegate and > @proxy > The same logic applies as for delgate, I wanted a verb instead of a > noun > (so it would have to be @forwardto - no so pretty) > Plus I wanted to keep it nice and short. :) > > My thinking is that "the delegates forward to the object that is > proxied", the the actual delegates (or forwarders) are the synthesised > methods and not the target object. > > Also a few notes on where Scala differs from vanilla Java, things make > a bit more sense knowing this: > > - all vals (immutable references) are by default made public final > (though you can override the public if you wish) > > - vals and vars are actually implemented as a private field, plus > accessor methods > So: > var x = "Hello World" > becomes (in equivalent java) > private String x = "hello World!"; > String x() { return x; } > String x_=(String x$ ) { x = x$; } > > This isn't quite accurate, as the generatted getter doesn't require > parens to call, and '=' isn't valid in a Java method name (it's > actually encoded as "$equals"), but it does illustrate the principle. > Surprisingly, '$' is valid in an identifier, but strongly discouraged > in handwritten code because it risks clashing with generated stuff. > Also, member variables and methods occupy the same namespace in scala. > > - classes have one primary constructor, other constructors can be > written but must delegate to the primary > This means that you have a guaranteed construction path for variables > that simply must be created, > there's no way to sidestep by having a second constructor - this helps > avoids a few nasty problems > > The primary constructor is all the code between the opening and > closing braces of the class definition, except for method > definitions. Variables (typically) declared here get lifted to the > status of class members. > > - if you need to pass 'this' to the object that you're forwarding to, > scala can help with lazy vals > i.e. > > class Foo { > @proxy lazy val bar = new Bar(this) > //bar is initialised when first accessed > > } > > - traits... > A Scala trait is internally generated as both a class and an > interface. > This means that if Bar is a trait then it's also an interface, and > that interface can also be synthetically added to Foo's superclasses. > [in more depth: The class contains just static methods that all take > an additional 'self' argument, so they know the instance they're > operating on. Instances of the trait (usually some other class plus a > mixin) then have generated methods that forward to the static > implementations - this allows for compound types such as "Cube with > Colour" where all methods from the Colour interface are implemented in > "Cube with Colour" as forwarders.]
Another issue to contend with is what should happen if Bar is final and possibly doesn't even have an interface. What if instead of Bar I was proxying a String, for example? I still want it to do *something* useful! In this case, Foo obviously can't be used as-a String. What I plan to do here is have Foo implement any interfaces that are available, so in this case Foo would be useable as a CharSequence and would additionally have any extra methods made available from the String type - it just wouldn't expose these via a named interface. Things like Comparable and Serializable could also make for an interesting challenge. My current thinking is to not proxy these interfaces, but require that they be explicitly declared if necessary. > On Nov 24, 9:21 am, Graham Allan <grundlefl...@googlemail.com> wrote: > > > > > > 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" > > > Is it such a black-and-white scenario? I would have thought there were a few > > caveats with which publishing 'this' in the constructor is safe. So within > > either object's constructor the following should hold: > > > - foo = new Foo(this) is called last, after the state of the object has been > > setup > > - Foo does not publish Bar > > - Foo does not mutate Bar > > - Bar does not publish Foo within the constructor > > > I've not read the reference you gave though, so I expect I'm missing > > something, but I'd be surprised if there were no conditions under which > > passing 'this' into a composed object in the constructor is unsafe. > > > Kind regards, > > Graham- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
