Thanks.
If you think this is cool, remember - this is only the first step. Ultimately, there will be a complete class hierarchy in parallel to the regular java class hierarchy, but without the constraints that the Java class system has (and without the OvrlyLongNamesForClasses.andStupidlyNamedMethods().
For example, yesterday I re-implemented the TPoint, TDim (dimension) and TRect classes for a future release that will not use the standard java classes.... there are no separate getter/setter methods named getX and setX, just an overloaded x() operator that allows you to optionally set the value of x. Also very handy for chaining ... so you can do stuff like rect2.x(rect1.x(42)) to set both rectangles x coordinate in one line, or rect2.x(rect1.x()) to set rectangle 2 left to whatever rectange 1 left is.
I've been using this style for ... gee, since before the web or java were invented ... and I don't understand why nobody else has come up with anything similar. I guess people just like to make things more complex than they should be.
BTW - you can do the same thing in languages that don't support operator overloading, just check the number of parameters to determine if you need to set a value before returning a value.