“Properties are bad and should not be allowed in Java” – LOL no properties (have to laugh)

“Public field access is mostly understood as a fast, failsafe operation but “property access” is NOT” – I’m afraid I have to be the one to tell you that’s the whole point (abstraction at the cost of performance – let the developers decide the intended use) LOL

“I like this syntax to disappear anyway” – So why you bringing it up as a point? LOL

“It’s next to impossible to get this right in the compiler” – Really? Heard of .NET? LOL

“Look at how badly it’s broken in C#” – Um, reflection works like a charm – we emit code and properties at runtime. More than 10 people seem to be ok with the system, so I’d say that it’s not really broken LOL

“More and more C# programmers are warning adepts *not to use* properties and to write explicit accessors instead” Yeah right! LOL

… Thanks very much for providing my entertainment for the day (this post and the comments). Ah man, I couldn’t stop laughing. I have to give them props, if Java “programmers” do have one useful skill, if nothing else, it’s that they sure are funny. Next thing you know they’ll be recommending to not JIT anything and go backwards by always compiling at runtime.

-Sean Noble

———–
This blog post comment is designed offer humorous reflection upon why in the world Java 7 still doesn’t have properties. Shows why Java’s not nearly as popular as it could be. Seriously though, good luck getting intelligent people in place as the decision makers. Seems like yall have your work cut out for you. Best wishes.

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]