Some silly ideas!

Question

Hello!
I'm talking to pros here, and I'm just a student :) However, I have some ideas about the language (to me they are improvements!) that I want to share with everyone. They might be just old and silly. If that's the case, plz tell me why those things would not work well :)
Borland�s idea of setting and getting a member of a class is extremely convenient. Instead of declaring a lot of set and get functions to do the job of accessing and alternating member variables of a class, declare those members public and assign specified set and get methods to them like the following:
public class Time {
     public int hour set = setHour get = getHour,
          int minute set = setMinute get = getMinute,
          int second set = setSecond get = getSecond,
     public void setHour(int h) {
          if (h>=0 && h<24) {
hour = h;
} else {
     hour = 0;
public int getHour() {
     return hour;
By doing this, when a client tries to modify or get the value of a member, we can write the code simply like this:
     Time myTime = new MyTime();
     myTime.hour = 24;
     System.out.println(myTime.hour);
This still guarantees the consistence of the object since accessing to the �public variables� is done through class designer�s defined methods.
What to consider here is the syntax to accomplish this purpose (should we define something called �method variable� like Borland did to their C++ Builder and Delphi? Should we limit the form of set and get methods like the above?).
Java passes by value all primitive types and by copy of reference all the object types. This makes it difficult when we want to return many values after a method call or alternate a value passed to a method (such as swapping). To accomplish swapping we can use a binding class since we can directly manipulate the references of the members of a class. However, we must declare each binding class for each type we want to modify, and this is still limited to object types.
Consider this kind of passing parameters to a method:
     public void doSomething(value(s); reference(s));
This way we can achieve all of those two tasks above. We can omit pass-by-references by omitting the semi-colon or omit the pass-by-values by putting nothing in front of the semi-colon. All the old Java codes, thus, can be reused without any modification.
Seeking for something new......

Answer 1

"...idea of creating set and get methods this way does not harm encapsulation or data hiding..." - I don't understand this.
Perhaps I haven't studied the C# model or proposed "improvement" to Java carefully enough, so I'll be happy to be educated if I'm not thinking properly.
If I expose a variable as a primitive double, that's all it can ever be. If I make it public, every client that accesses my variable and sets it with a double will be affected if I change it.
If I was doing high precision numerical work, and decided after public release that I wanted to change that data member from a primitive double to a java.math.BigDecimal, my clients have all got a problem. They've all written code to set that public member to a double, and my type change breaks all their code.
Buf if I've hidden that data member behind a getter that takes a double argument and a setting that returns a double, I'm free to change the implementation and none of my clients have to know. No problem. They can still pass a double argument to my getter and get a double back from the setter. My BigDecimal handles everything for me under the covers and lets me have infinite precision. Very nice.
What if you have a getter method that does a database query behind the scenes? How do you hide that behind a public data member? What if the setter is doing a database INSERT/UPDATE? What if the getter is really doing a RPC to a credit check service to get back that simple boolean that you see? How do you hide that if the boolean is public?
You can hide those things behind a method interface. You can't if the data member is public and out there hanging in the wind.
I don't think it's more convenient. I don't think it's clearer. I don't want hidden methods generated to do things for me. If I want a public data member, then that's my design intent. If I want to hide the implementation, I want it to be my choice.
My API communicates design intent. I wouldn't like the idea of the language hijacking my choices behind the scenes.
I've skimmed the C# API. While I do agree that they've done some fine work and learned some good lessons from Java, there's a lot of stuff that I think still rots (e.g., retaining the #define compiler directive). I wouldn't hold up C# as the shining example in this argument. - MOD