Women in Technology

Hear us Roar



Article:
  10 Reasons We Need Java 3.0
Subject:   Really good ideas
Date:   2002-08-01 11:45:28
From:   cybarlow
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;


would be wonderful. C# cribbed a lot from Java; isn't turnabout fair play?

Full Threads Newest First

Showing messages 1 through 3 of 3.

  • Really good ideas
    2002-08-02 23:09:46  bchoi [View]

    >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.
    • 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
      • 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.