That’s just a flat out lie. There are no c# programmers evangelizing properties as Java does, and if you find one, they’re a moron. Properties are a very important part of the whole .net framework. C# coders live in that framework and to code in the backassward way as the framework would be ignorant.

1. Public field access is mostly understood as a fast, failsafe operation but “property access” is NOT. With such a syntax you have to prepare yourselves for a = operator (or, in case of the getter, worse still, the . “operator”) throwing at least runtime exceptions. But why disallow checked exceptions on accessors? And the fast bit: property access may use a database ot a webservice or whatever gizmo you can imagine and it may last seconds, not nanoseconds as we are mentally prepared with public fields.
2. What about x = y = z? Setters are void, and for a good reason, but you can’t have x = y = z without breaking this. It is a minor issue, though… and I like this syntax to disappear anyway
3. It’s next to impossible to get this right in the compiler. You should be able to replace the class with properties (a version using simple passthrough or plain public fields to a version using accessors or the other way around) without breaking its clients’ binary or source code. That means the compiler has to use indirection anyway because it cannot know whether or when you’re going to replace that library JAR.
4. This must be transparent as well to the Reflection API, and consistently with the source code. Look at how badly it’s broken in C#.

More and more C# programmers are warning adepts *not to use* properties and to write explicit accessors instead. Come to think of it, this was meant to be a real advantage and boost over Java and now most experienced C# programmers prefer and evangelize the Java way in C#.

So please leave the properties where their place is: in the “failed experiments” drawer.

I agree that it would be a really good idea to reduce the importance of “backwards compatibility” in these discussions. The need for it is often only perceived and not really needed. Take the “Generics” implementations for instance: lots of older code does not compile with -source 1.5. Which is no problem _at all_ because we _have_ -source 1.4! You can easily compile “legacy” code with a legacy version of the language; the only thing you need to keep “backwards compatibility” is to maintain the ability within the JVM to handle the generated code. This is how most “older” code is compiled nowadays anyway.

A good way to see how perceived “backwards compatibility” can really hurt is the Generics implementation. The moronic braindead idiot that allowed for type erasure should be shot! It has reduced the Generics system to a barely functional syntactic layer only, with really stupid limitations (why on EARTH would anyone in his right mind accept a generics implementation which is unable to do class … new T()” ) AND huge reduced functionality around Reflection and metaprogramming. And the reason for this enormous crappy cludge: they wanted to be backwards compatible with JVM 1.4… Which they aren’t anyway. Horror.

I would also make another point for all the people that do not want to extend the language because they think there are already other (usually more verbose ways) of doing whatever needs to be done. Think for instance about the “enum” functionality introduced in 1.5. A computer language is a way to express a problem solution. How effective you can be in expressing such a solution is a direct advantage: if you have to write “boilerplate” for very common solutions this is a problem of the language! It reduces the visibility of the “real” problem *and* it often reduces the knowledge that the compiler has about the actual thing being done - leading to lousy (or no) error messages or reduced code quality.
To me the plethora of stupid “getXxx” and “setXxx” methods is an indication of a blunder in language design. Saying I can do something in a language does not make it the right way because a good language is supposed to make common things easy.

I would advice people to look at C# for some examples of good language design, not only wrt to the language but also wrt the process: don’t be too afraid for changes.

Yes you are, because a property is not a public field, it doesn’t even have to _back_ a public field.

Let’s give a trivial and non-existent example: you’ve got a property a on your object A.

This means that you can, of course, call A.a and have a result back. Your property is a simple pass-through (ie you could’ve made your `a` field a public field and it would be the same. It _should_ be the same, in fact).

Now you realize that you should change your implementation, and that your private field `a` should really be replaced by a computation based on `b` and `c`, because your `a` private field really doesn’t pull its weight. Are you locked? Nope, just replace your passthrough interface by a computing one: instead of `return a` write `return compute(b, c)` and instead of `a=value` write `b, c = someInverseComputation(value)`. Boom, you’re done. And it’s very often what’s done in Python or Ruby. The _point_ of interface is that they _look_ like public fields (I like to call them “virtual public fields”) but they’re not. This really means that your interface is independent from the implementation, and the only reason why you use a property or a method is whether or not it makes sense.

And if properties and public fields behave the same at the interface-level (meaning that you can declare a public field in an interface, or a property, and they’re declared the same way, as long as there’s either a public field or a property that satisfies the contract everything’s ok) then you don’t have to wrap everything in getters and setters “just in case”, uselessly boosting the number of indirections and making the code less clear: you use public fields, and if you need to “hide” them or change your implementation, just swap them with properties.

Borland Delphi Pascal also has properties (wasn’t it, that the one how developed this language also was the creator of C#) and you can define the names of the getter and setter methods. These will be called, even if you access the property field directly:

[tt]
mybook.count = 3 ; // still calls setCount(…)
// for following declaration

type
Book = class
private
// User defined attributes
title: Char;
FCount: Integer;
// User defined methods
procedure setCount(cnt: Integer); virtual;
…
public
…
// Access methods
function getTitle: Char;
procedure setTitle(newTitle: Char);
// Properties
property count: Integer read FCount write setCount;
…
implementation
…
[/tt]

If you take the idea of mapping primitive syntax to method, you could also define that [] mapped to elementOf (or whatever name you choose) and [] = mapped to setElementOf, and was legal for any class, so Maps and List could use the same syntax as arrays. I believe Dylan (an language which tried to make Common Lisp look more like a standard language) did this, and this resulted in quite nice code to both write and read.

I know this looks a bit like operator overloading, but it’s different from and not as dangerous as overloading the mathematical operators (like + and -), where you expect certain rules from algebra to apply.

A meta comment: It seems to me that some people participating in this (and other) discussions assume Java’s designers were ignorant of these problems and/or their possible solutions. I think that’s wrong, e.g. Guy Steele co-wrote the Common Lisp specification, and was at Sun early enough to influence the design of Java. There are so many opinions about these things that it’s good that they didn’t make decisions about them too early. Whether we can reach consensus on adding keywords like property (which I think is a good idea, based on my experience with CLOS) now is a different question. It will also be interesting to see if the open sourcing of Java makes the process more open to such suggestions (as long as they’re compatible with the JVM).

Partly. The principle at stake here is that changing the implementation should not break the interface. A property mixes implementation (the variable holding a value) and interface (how the property is accessed), just like a public variable. Getters/setters separate interface from implementation. That’s why ‘the first reason doesn’t apply to regular getters/setters’, but does apply to properties. Or am I missing something here?