ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  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:


a.getB().setC(d.getE().getF());
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


1 to 1 of 1
1 to 1 of 1