10 Reasons We Need Java 3.0
Subject:   pros and cons of properties
Date:   2002-08-06 18:30:02
From:   rayburns
Response to: Really good ideas

Having written a.getB().getC().setD(e.getF().getG()) too many times, I think adding properties to Java is a no-brainer. Public fields are extremely rare in well-written code, but the fact is that hundreds of real Java applications use them because getX() and setY() are too inconvenient and potentially inefficient!

The only good argument I've ever seen for leaving out properties is that client code may make incorrect assumptions about the efficiency of "x.y". But this argument fails for two reasons:

1. It assumes a Java mindset rather than a C++ or VB mindset
2. It does not preclude using a different syntax for direct field access when such access is necessary

An example of different syntax:

"x.a" indicates property access and "x..a" indicates direct field access. In other words, replace this:

g.internalThing = h.getI();

with this:

a.b.c = d.e.f;
g..internalThing = h.i;

The second case is more readable and it is still easy to distinguish property access from field access.

However this seems like an unnecessary syntactic crutch. I prefer a class contract approach. For example, here's a contract that sum() takes O(N2) time and property x is a trivial access that can be inlined into the client code:

// <contract>
// <performance method=sum complexity=order_N_squared />
// <performance property=x complexity=direct_acccess />
// ...
// </contract>

Ray Burns

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • pros and cons of properties
    2002-08-12 11:37:33  jacyg [View]

    The biggest problem that I see with properties is that they are just another syntax for a method, but rather than enhancing clarity, they decrease it. For example, there is nothing in the signature of a C# class (C# being a good mainstream model for properties) that makes it clear that it is read-only, write-only, or read-write. However, the presence or absence of the appropriate get() and/or set() method makes that abundantly clear. Yes, it may take a few more characters, but the generated code is the same. We should not be introducing new features in to the language that accomplish the same thing other features do. The willingness to do so will eventually render the language confusing and bloated, rather than streamlined and easy to understand. The best example I can think of is the number of ways to specify a String in Windows C++ development. Do you think a multiplicity of ways to do that same task makes the language better? I don't.