Re: the Java Lang will support Properties in Futuere?

On Sun, 16 Nov 2008 18:37:19 -0800, Lew <noone@xxxxxxxxxxxxx> wrote:

Peter Duniho wrote:
Huh? Is "A" (or "a") a property or not? If it's a property (and there's nothing about the code you posted that insists that it's not), then you use the property syntax. If it's not a property, then you use the method syntax.

What is the advantage of language support for a property with "dot-foo" syntax compared to a public member Java-style?

Currently Java supports having properties with a dot syntax by dint of public instance variables, something that is conventionally regarded as anathema.

That's not a property. That's a variable. A property is an abstraction. As an abstraction, it allows the class to provide an arbitrary implementation as long as it fulfills the specific contract of getting and setting a value of a given type. A variable does not allow the class to provide an arbitrary implementation; the implementation is a given, and does nothing except for store or retrieve a value into or from the variable.

The common excuse given for turning those into get/set methods is to allow additional logic in the method while keeping the actual implementation hidden. Does property syntax provide advantages similar to method syntax?

Since there are no properties supported by Java, it's impossible to say exactly what they would look like in Java.

But yes, in other languages they are a language construct that defines the members as a pair of methods. That is, it codifies the same convention used in Java. For example, in C# when you define a property, it has a getter, a setter, or both. You can declare a property using the "auto-implement" syntax:

public int MyProperty { get; set; } // must always have both get and set

Or you can declare the property explicitly, to allow for additional functionality:

private _MyProperty;
public int MyProperty
get { return _MyProperty; }
_MyProperty = value;
RaiseMyPropertyChanged(); // for example

You can do basically anything you want in the getter and setter. The above is a typical basic scenario where all you want to is to raise an event when the property changes (thus the call to the hypothetical method RaiseMyPropertyChanged() method), but other than the requirement that the getter actually return a value of the same type as the property, there really aren't any restrictions.

You can also implement read-only properties or write-only properties by leaving out either the getter or setter, and the getter and/or setter can have different (more restricted) accessibility than the property itself, providing for a property that is (for example) publicly read-only, but which has a setter accessible from with the class, assembly, etc.

The most common use of properties is the same as the convention in Java: providing value-centric access to a member, but going through methods that allow for things like range-checking, raising events, etc. Another very common use in .NET of properties is to provide named access to values for use in library controls. For example, you can set the "DisplayMember" property (a string) of some kinds of controls to the name of a property of some other object that is referenced by that control. The control then uses that named property to retrieve a value to display within the control to represent that object.

A specific example of this would be a ListBox containing some list of objects that the user can select from. The object type contained in the list might have a property that provides a user-friendly name, and a different property that provides the value associated with that user-friendly name. Using the DisplayMember and ValueMember properties of the ListBox class, you can easily configure the control to display to the user the user-friendly name of each object, but then return for the SelectedValue property the actual value associated with that object (or even the object itself if you prefer).

More generally, the entire framework of data binding in .NET, a broadly supported and used feature in a wide variety of applications, relies on properties to do a lot of the heavy-lifting.

A lot of this is possible without language support. For example, consider Apple's framework Cocoa, using Objective-C. Until last year with the release of Objective-C 2.0 there was no language support for properties at all, and even now the support is minimal (not nearly as much a core feature of the language as it is in C#). Yet, they have a lot of the same kinds of data binding features in the framework that .NET has.

Instead of relying on built-in property support for the language, they just stipulate that you have to follow their "Key-Value Coding" conventions (very similar to the "getMyProperty()/setMyProperty() convention" in Java). Then the framework builds the appropriate names for the "selectors" used (in Objective-C, objects don't implement methods, they respond to selectors used to send messages...the net behavior is the same though). In the end, it mostly winds up being the same as data binding in .NET, even though the underlying language and framework is very different.

Java could do the same, and for all I know it does. I haven't run into any data binding features in Java, but then I haven't used Java as much as some of these other frameworks, and so it's not something I've looked to explore. There's no reason that in Java if you wanted to do (for example) data binding, you couldn't just build the appropriate method name from the property name by prepending "get" or "set" to it and using reflection to get the method to invoke.