Women in Technology

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