Women in Technology

Hear us Roar



Article:
  10 Reasons We Need Java 3.0
Subject:   Really good ideas
Date:   2002-08-02 23:09:46
From:   bchoi
Response to: Really good ideas

>I agree with all of these reasons for refactoring Java. Didn't the addition of assertions and generics to Java begin to open this door? At any rate, if anyone from Sun is reading: making bean properties that are accessible through getProperty and setProperty methods accessible like this:
somebean.someproperty = 5;
somevar = somebean.someproperty;


I dun agree with that. I would like to be able to tell if I'm dealing with a method or primitive from the syntax. They should be treated differently.


bean.setProperty(5) is not unreadable.

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • pros and cons of properties
    2002-08-06 18:30:02  rayburns [View]

    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