Also, this interface thing Charles wants sounds like Traits in Scala. I think traits are interfaces that can also contain some implementation details. Thus, a class that extends a base class can gain canned implementation details by implementing one or more Traits; this provides code reuse that would otherwise require multiple-inheritance.

This leads to some really nasty practices. Take a look in the Eclipse APIs for example, you’ll find an interface called IActionDelegate and another one called IActionDelegate2 which extends IActionDelegate and adds some methods. The worst aspect of this is that the API code in Eclipse has to take in instances of IActionDelegate, and then use an “instanceof IActionDelegate2″ to see whether it’s possible to call the newer methods.

Incidentally, some people would see this mess as a good argument for dynamic languages — after all this wouldn’t happen in Ruby with duck typing, right? However, I think it’s an argument for making Java’s typing system less broken. Scala, for instance, is a statically typed language but its type system actually works.

I am using Rhythmbox on Linux, so maybe that’s why. I notice similar behavior when using PenguinTV.

He interrupts and even takes a personal cell phone call in the middle of the conversation.

It’s a pity.

Congratulations to you, though.

I’ll get right on the fact checking department here at drunkandretired.com for allowing these slips to contaminate the high quality of journalism our listeners have come to expect ;)

In any case, keep up the good work, and if your proposal doesn’t make it into java 7, rest easy knowing that we think it should!

First, using a property-read to generate a side effect other than auditting is almost always totally bogus. I think your delphi experience was abuse of properties, and not an intrinsic flaw in properties.

More generally, I guess the point I was trying to get at with my rant on properties, and then later about doing away with interface impl separation (at least from the perspective of a reference holder) is that I think *everything* should be a reference to an interface. Thus, there is no such thing as a “member variable.” That’s implementation specific, all you know is that there is an interface to get a value called “width” from a Window. How it is stored, where it is stored and how often it is recalculated is not your business.

As for straight forward public member variables, I agree, they do have their place, but inevitably you’re going to want to “upgrade” some of them at some point. Trust me on this one, I’ve made 3 major attempts in Java to systematically use public member variables as a stand in for properties in the last year and all of them have failed spectacularly.