the Java Lang will support Properties in Futuere?

[mttc]

As other criticism on Java, Properties is also big missing. Many say
what problem with get or set?
the answer is simple. it's true! the get and set it's good. The
problem is when we use it:

i=s.getX();
s.setX(i);

why Java (after so many years) not able to give us simple code (as
Delphi):

i=s.X;
s.X=i;

There have many debate and page on the Internet. I say to java Leaders
do what developer ask!

And why the Netbean not support get & set when the list of members
pop, why we got the getXX separate then setXX for the Same properties?
let's Change the list to:
property X
property Y

instead of:

get X
get..
get..
get..
...
set X
...

I see the Bean-Properties Project, it's seem very poor solution. the
correct way is do it in the lang itself. but Java Guys not going to
confess on this big mistake. therefor we continue wasting time to
search right set or get from long members list. or typing extra dots
and parenthesis (or yield.. ).

 

[Mark Space]

the answer is simple. it's true! the get and set it's good. The
problem is when we use it:

i=s.getX();
s.setX(i);

I see no problem with this.

why Java (after so many years) not able to give us simple code (as
Delphi):

i=s.X;
s.X=i;

I don't like Delphi.

There have many debate and page on the Internet. I say to java Leaders
do what developer ask!

Yes, do what developers ask, don't change it. Leave the setters and
getter alone.

And why the Netbean not support get & set when the list of members
pop, why we got the getXX separate then setXX for the Same properties?

Because there are read-only (just getX) and write-only (just setX)
properties?


Sorry but I don't see any call for emulating Delphi. I'm afraid you are
a voice crying in the wilderness alone.

 

[Lew]

mttc wrote:

In a blatant and rather illiterate attempt to start a flamewar:

I see no problem with this.

Nor I.

I don't like Delphi.

Apparently a universally-held opinion. This is the first and only time I've
ever heard of anyone holding up Delphi as an exemplar of good practice.

There have many debate and page on the Internet. I say to java [sic] Leaders
do what developer ask!

Yes, do what developers ask, don't change it. Leave the setters and
getter alone.

Hear! Hear!

What does this even mean? Are you saying that NetBeans doesn't let you
automatically create both getters and setters automatically in a single
action? If so, you're mistaken.

And even if whatever you said were true, that's on NetBeans, not Java.

Because there are read-only (just getX) and write-only (just setX)
properties?


Sorry but I don't see any call for emulating Delphi. I'm afraid you are
a voice crying in the wilderness alone.

There is a strong current of what I call laziness among some developers who
just can't seem to stand typing anything. For those folks, the extra
characters in a method call compared to declaring, say, a public member are
anathema. To those folks, I say, "Awwww!" And, "Use your IDE." Both Eclipse
and NetBeans support auto-generation of getters and setters for your
properties. If you really cannot stand the rigor of method-oriented
properties, then don't use Java. We won't miss you at all.

No pity for you, mttc. Buh-bye. Ta-ta. See ya, wouldn't want to be ya.

 

[Joshua Cranmer]

As other criticism on Java, Properties is also big missing. Many say
what problem with get or set?
the answer is simple. it's true! the get and set it's good. The
problem is when we use it:

i=s.getX();
s.setX(i);

why Java (after so many years) not able to give us simple code (as
Delphi):

i=s.X;
s.X=i;

The benefit of the latter form is more circumspect. In the three
languages that I have experience with where this feature is
implemented--PHP, (Mozilla) JavaScript, and python--I have found this to
be a barrier to comprehension at least once in each language, often
times multiple times.

I don't profess to know all the use-cases for Java programming, but I've
never really felt such a feature to be needed. At least in the projects
I've mucked around in, writing getters/setters for everything naïvely
tends to be frowned upon. The boilerplate it would reduce is small, but
then again, most of the same cases can be made against the for-each loop.

If your main reason for proposing feature inclusion is "XXX language has
it," I recommend you just drop the idea. Why not include all those nice
features that Cobol has, then?

There have many debate and page on the Internet. I say to java Leaders
do what developer ask!

Let's see what developers think. According to
<http://www.javapolis.com/confluence/display/JP07/Whiteboard+results+-+Language+change>
(the site seems to be down, so I checked the Way Back Machine)... hmm,
the information is in images which are presently inaccessible.

Looking around on Google, I get this summary of results
(<http://www.jroller.com/scolebourne/entry/voting_on_java_7_language>):
There was some support for Better null handling (with a new operator)
and Properties. The balance was slightly against, but not overwhelming.

Recalling from memory, I think there was a fair number of "don't care
votes," but don't hold me to that.

So it seems that developers aren't as gung-ho about the feature as you
imagine.

I see the Bean-Properties Project, it's seem very poor solution. the
correct way is do it in the lang itself. but Java Guys not going to
confess on this big mistake. therefor we continue wasting time to
search right set or get from long members list. or typing extra dots
and parenthesis (or yield.. ).

I only use IDE autocompletion when I can't remember the name of a method.

Your complaint about having to view too many members in a list doesn't
really make sense (you'd have just as many properties as you did
getters...), and having to type 5 extra characters (4 for the setter)
isn't exactly overwhelming, since that would be less than the average
property name.

Java has undeniably bigger mistakes--not making int an object is one
(mostly ameliorated via auto-(un)boxing), and the lack of generics
reification is another. In both cases, certain tasks become actually
impossible without having to throw more stuff around, as opposed to the
lack of a properties where the workarounds consist of typing a few more
characters.

 

[Arne Vajhøj]

There have many debate and page on the Internet. I say to java [sic]
Leaders
do what developer ask!

Yes, do what developers ask, don't change it. Leave the setters and
getter alone.

Hear! Hear!

There are Java developers that would like to see properties and
my understanding is that it is heavily discussed for Java 1.7.

Personally I do not see the point though. A method call should
look like a method call.

Arne

 

[Arne Vajhøj]

Apparently a universally-held opinion. This is the first and only time
I've ever heard of anyone holding up Delphi as an exemplar of good
practice.

I conclude that you do not attend groups & forums with many
Delphi programmers then.

There are a lot of Delphi programmers that really like Delphi.

And it is not a bad language. I have never really appreciated
the Delphi environment. But the Pascal language is great. A
good language with a decent typing system. It do have its
limitations, but they are fixed in newer languages like
Modula-2 and Ada.

Arne

 

[Mike Schilling]

mttc wrote:
There have many debate and page on the Internet. I say to java
[sic] Leaders
do what developer ask!

Yes, do what developers ask, don't change it. Leave the setters
and
getter alone.

Hear! Hear!

There are Java developers that would like to see properties and
my understanding is that it is heavily discussed for Java 1.7.

Personally I do not see the point though. A method call should
look like a method call.

The usual point is that if you have a property-like thing, then

1. Client code needn't be aware whether you implement it as a field or
a getter/setter pair
2. You should be able to change that (almost always from field to
method pair) without changing client code.

Both of these are sensible enough, but undercut by

A. No one with any sense would implement it as a public field in the
first place.
B. In almost all implementations (including .NET), even if the syntax
for client field access and client property access are identical, the
generated code is quite different, so the change requires recompiling
all the clients anyway. That is, even if it's source compatible, it's
binary incompatible, and thus a very bad idea in a library.

So you're left with argument C:

C. No one with any sense has mutable public fields, so syntax like

a.foo = 12;
b = a.foo; / lowercase "foo", thus not a constant

is more or less unused, and thus available to distinguish between
properties and other sorts of methods.

Less compelling, at least IMHO.

 

[Daniel Pitts]

mttc wrote:
There have many debate and page on the Internet. I say to java [sic]
Leaders
do what developer ask!

Yes, do what developers ask, don't change it. Leave the setters and
getter alone.

Hear! Hear!

There are Java developers that would like to see properties and
my understanding is that it is heavily discussed for Java 1.7.

Personally I do not see the point though. A method call should
look like a method call.

Arne

I think that if anything, there should be syntax to easily generate the
getters/setters (Yes, my IDE will generate them for me, but I think
there could be a more clear concise approach)

Perhaps something like:

public class MyBeanType {
private final int x;
private double y;

// Generates: int getX() { return x; }
public readproperty int x;

// Generates: double getY() { return y; }
// void setY(double y) { this.y = y; }
public readwriteproperty double y;
}

The uniform access principle is preserved:
<http://en.wikipedia.org/wiki/Uniform_access_principle>
<http://c2.com/cgi/wiki?UniformAccessPrinciple>
Clarity of intent is added. It also makes javadoc easier to make clear.

 

[Mike Schilling]

Mark Space wrote:
mttc wrote:
There have many debate and page on the Internet. I say to java
[sic] Leaders
do what developer ask!

Yes, do what developers ask, don't change it. Leave the setters
and getter alone.

Hear! Hear!

There are Java developers that would like to see properties and
my understanding is that it is heavily discussed for Java 1.7.

Personally I do not see the point though. A method call should
look like a method call.

Arne

I think that if anything, there should be syntax to easily generate
the getters/setters (Yes, my IDE will generate them for me, but I
think there could be a more clear concise approach)

Perhaps something like:

public class MyBeanType {
private final int x;
private double y;

// Generates: int getX() { return x; }
public readproperty int x;

// Generates: double getY() { return y; }
// void setY(double y) { this.y = y; }
public readwriteproperty double y;
}

The uniform access principle is preserved:
<http://en.wikipedia.org/wiki/Uniform_access_principle>
<http://c2.com/cgi/wiki?UniformAccessPrinciple>
Clarity of intent is added. It also makes javadoc easier to make
clear.

What if you want more complex implementations, e.g. synchronization or
logging changes?

 

[mttc]

thanks for all. I learn a lot and now I filling more comfortable with
Java properties style.

But after all, i think that is will better if Java support the Delpi
style:

+for all guy that hate Delphi & VB and many others (I'm hate VB so I
mention Delphi). this is not a Man or women that you love or Hate.
this is a tool for your livelihood. So the point is with what your
code is going more clear and quickly. So the discussion is must around
this. All of you not talking about the problem but refuse to see it.

+Please give me one reason that Proprties Java style is better! (clear
or quickly)

+Convince me that IDE that the Side effect of Java style on IDE (on
Completion Long list, with getXX seperate setXX),
Instead one line for each property with indicates [R,W,RW]. We can
add more shortcut that focus on Read or Write.

+Convince me that coding extra typing extra dots (with Bean-Properties
Project) and parenthesis is Rapid my work.
You call it "laziness". I know that. But in other side if Java
support it, what benefit we loost? and nevertheless we benefit for a
lot developers that coding like: i=s.X is more clear & rapid for tham.

So my main Claim. the Java guys behave like Academy that disconnected
from the workers. and this cause that Java is will not growing like we
want. microsoft is behave like A dog. the dog is run ahead, but
looking behind where his owner go. this is stupid behave But is
succesfully. I not suggest to behave like Microsoft, but I say:

When many developers want somthing that not spoil the Lang, do it. But
Java guys seem like Philosoph on rome gate that try to fix our life.


Some other mistakes argument is appear on the answer like:

"the user not suppose to know that it is Field".

this is not true. Also in Delphi style Property is regular subroutine.



Where I can find the official site for: what new in 1.7?

 

[Joshua Cranmer]

+for all guy that hate Delphi & VB and many others (I'm hate VB so I
mention Delphi). this is not a Man or women that you love or Hate.
this is a tool for your livelihood. So the point is with what your
code is going more clear and quickly. So the discussion is must around
this. All of you not talking about the problem but refuse to see it.

As I pointed out earlier, the fact that some other language has a
feature isn't a reason to include it in Java per se. So the fact that
Delphi has this feature is almost entirely moot.

+Please give me one reason that Proprties Java style is better! (clear
or quickly)

Billions of lines of code use it already.

+Convince me that IDE that the Side effect of Java style on IDE (on
Completion Long list, with getXX seperate setXX),
Instead one line for each property with indicates [R,W,RW]. We can
add more shortcut that focus on Read or Write.

IDE autocompletion will typically look like this:

(assuming 4 entries in the dropdown)
getPropertyA
getPropertyB
getPropertyC
getPropertyD

and:
setPropertyA
setPropertyB
setPropertyC
setPropertyD

Under your proposal, the dropdown would look like this:
propertyA
propertyB
propertyC
propertyD

No real difference that I can see.

So my main Claim. the Java guys behave like Academy that disconnected
from the workers. and this cause that Java is will not growing like we
want. microsoft is behave like A dog. the dog is run ahead, but
looking behind where his owner go. this is stupid behave But is
succesfully. I not suggest to behave like Microsoft, but I say:

Java was not designed for academic purposes. It was originally designed
to be a "safe subset" of C++, hence why it does not do features like
multiple inheritance or operator overloading.

When many developers want somthing that not spoil the Lang, do it. But
Java guys seem like Philosoph on rome gate that try to fix our life.

I'm really getting parse errors here, but I'll do my best to understand.

In any case, the feature in question is not zero-cost. First, there is
the not-insignificant cost of a new feature being added. A second cost
is that property support makes name resolution--a difficult step
already--somewhat more difficult. A final cost is the enormous cost of
sucking up a keyword.

Any benefits that the feature may bring would have to face up to these
costs. I fail to see an overwhelming benefit to the feature that would
justify creating a new keyword (especially one which is probably
relatively common in usage!) or even just justifying its addition to Java.

At best, it's syntactic sugar, and sugar that doesn't add type safety at
that. At worst, it perpetuates anti-patterns. Although there's no strong
reason to stop it from becoming part of Java, there's no strong reason
to make it part of Java, and in case of a tie, the exclusionists have it.

Where I can find the official site for: what new in 1.7?

The answer is "nowhere, at least for now." Superpackages/modules and
type annotations will almost definitely make it in, language-wise. The
only other proposal with serious work done on it is closures, and
that... Let's just say that its inclusion (in any version) is not set in
stone. It's possible that other small features may be included if
someone gets around to writing a JSR on them and getting working
prototypes, but the timeframe makes it look unlikely.

 

[Daniel Pitts]

What if you want more complex implementations, e.g. synchronization or
logging changes?

Then you have to write an actual getter/setter methods. This is a
simplification for 80% of the getter/setters out there, not a catch-all
replacement. The point of the syntax I suggest is that it could be
compile-time and run-time compatible with getters/setters as they are
used today.

 

[Arne Vajhøj]

The usual point is that if you have a property-like thing, then

1. Client code needn't be aware whether you implement it as a field or
a getter/setter pair
2. You should be able to change that (almost always from field to
method pair) without changing client code.

I don't think that #2 is true for all property implementations.

A. No one with any sense would implement it as a public field in the
first place.
B. In almost all implementations (including .NET), even if the syntax
for client field access and client property access are identical, the
generated code is quite different, so the change requires recompiling
all the clients anyway. That is, even if it's source compatible, it's
binary incompatible, and thus a very bad idea in a library.

Yep.

Arne

 

[Arne Vajhøj]

Mark Space wrote:
mttc wrote:
There have many debate and page on the Internet. I say to java
[sic] Leaders
do what developer ask!

Yes, do what developers ask, don't change it. Leave the setters and
getter alone.

Hear! Hear!

There are Java developers that would like to see properties and
my understanding is that it is heavily discussed for Java 1.7.

Personally I do not see the point though. A method call should
look like a method call.

I think that if anything, there should be syntax to easily generate the
getters/setters (Yes, my IDE will generate them for me, but I think
there could be a more clear concise approach)

Perhaps something like:

public class MyBeanType {
private final int x;
private double y;

// Generates: int getX() { return x; }
public readproperty int x;

// Generates: double getY() { return y; }
// void setY(double y) { this.y = y; }
public readwriteproperty double y;
}

The uniform access principle is preserved:
<http://en.wikipedia.org/wiki/Uniform_access_principle>
<http://c2.com/cgi/wiki?UniformAccessPrinciple>
Clarity of intent is added. It also makes javadoc easier to make clear.

I think it was something like that which was discussed for Java 7.

But I don't think it is that much more clear than traditional get
and set.

Arne

 

[Arne Vajhøj]

Personally I do not see the point though. A method call should
look like a method call.

Which means that I am against properties until it is
possible to have the language/compiler impose restrictions
on the get and set so that they are not general methods.

Arne

 

[Lew]

The answer is "nowhere, at least for now." Superpackages/modules and
type annotations will almost definitely make it in, language-wise. The
only other proposal with serious work done on it is closures, and
that... Let's just say that its inclusion (in any version) is not set in
stone. It's possible that other small features may be included if
someone gets around to writing a JSR on them and getting working
prototypes, but the timeframe makes it look unlikely.

Calendar / date / time improvements seem like they'll make it.

 

[Lew]

thanks for all. I learn a lot and now I filling more comfortable with
Java properties style.

But after all, i [sic] think that is will better if Java support the Delpi [sic]
style:

+for all guy that hate Delphi & VB and many others (I'm hate VB so I
mention Delphi). this is not a Man or women that you love or Hate.

Urrr? You are showing more passion than anyone else on this thread, so we
have a case here of the pot calling the kettle black.

this is a tool for your livelihood. So the point is with what your
code is going more clear and quickly. So the discussion is must around
this. All of you not talking about the problem but refuse to see it.

Flamebait. Disagreeing with you is not the same as "refusing to see it".

You have not established that your proposal is more clear than the /status quo/.

+Please give me one reason that Proprties Java style is better! (clear
or quickly)

At least you said "please".

Please give us one reason why your proposal's benefit exceeds its cost. Be
clear, and account for the costs others have already pointed out.

+Convince me that IDE that the Side effect of Java style on IDE (on
Completion Long list, with getXX seperate setXX),

I am willing to bet that no one here is going to convince you of anything if
they disagree with anything you've said.

Instead one line for each property with indicates [R,W,RW]. We can
add more shortcut that focus on Read or Write.

What does an IDE feature have to do with Java syntax changes? If you don't
like an IDE feature, take it up with the folks that work on that IDE.

+Convince me that coding extra typing extra dots (with Bean-Properties
Project) and parenthesis is Rapid my work.

I am willing to bet that no one here is going to convince you of anything if
they disagree with anything you've said.

Also, I am completely unclear what you mean by "extra typing extra dots".

I type 90 words a minute, at top speed, or roughly 7.5 characters a second.
Even without IDE assistance, the extra time spent with method-oriented
properties compared to your suggestion is 1-2 seconds, time spent not thinking
about my typing but about the code itself and the logic thereof, so there is
no actual loss in productivity. Perhaps you just need to learn to type
better, and to think while you are typing?

You call it "laziness". I know that. But in other side if Java
support it, what benefit we loost? and nevertheless we benefit for a
lot developers that coding like: i=s.X is more clear & rapid for tham.

You have not established that it's more clear or more productive your way.

So my main Claim. the Java guys behave like Academy that disconnected
from the workers.

Flamebait, and point not previously made, much less established.

and this cause that Java is will not growing like we want.

You mean like you want. The rest of us either don't care or don't care much.

microsoft [sic] is behave like A dog. the dog is run ahead, but
looking behind where his owner go. this is stupid behave But is
succesfully. I not suggest to behave like Microsoft, but I say:

Microsoft has nothing to do with the shape of Java.

When many developers want somthing that not spoil the Lang, do it. But
Java guys seem like Philosoph on rome gate that try to fix our life.

Much like you seem to be doing. Anyhow, you have provided no evidence that
any developers want what you propose, much less "many developers". Even those
here who like the properties feature à la mttc have pointed out that its
benefits don't outweigh the costs.

Personally, I see it as a nice feature when present, maybe, but not of any
particular benefit.

Some other mistakes argument is appear on the answer like:
"the user not suppose to know that it is Field".

Begging the question.

this is not true. Also in Delphi style Property is regular subroutine.

Irrelevant.

Nice try on the flamebait.

 

[Mark Space]

Because it's what everyone has been using. There are huge volumes of
code that depend on the current property idiom and it pretty much works
fine.

Personally, I like language-supported properties. But as long as people
follow standard conventions, you can get nearly all the benefit of
baked-in properties using regular methods. One of the biggest

Reading this thread, I think this attitude is reversed. Sure, this
"hides" from the user whether a is a property or field:

foo.a = 1;
int a = foo.a;

But what if "a" isn't a property?

public void setA( int i ) {
outputStream.write( i );
outputStream.flush();
}

public int getA() {
// read from file or DB...
}

How does this work when the expected syntax is .propertyName? I think
using the . syntax forces you to distinguish between "real" properties
that are supported by the baked-in language property feature, and
pseudo-properties that must be supported by method calls. Using the
method call syntax for both provides the better abstraction, imo.

 

[Lew]

Huh? Is "A" (or "a") a property or not? If it's a property (and
there's nothing about the code you posted that insists that it's not),
then you use the property syntax. If it's not a property, then you use
the method syntax.

What is the advantage of language support for a property with "dot-foo" syntax
compared to a public member Java-style?

Currently Java supports having properties with a dot syntax by dint of public
instance variables, something that is conventionally regarded as anathema.
The common excuse given for turning those into get/set methods is to allow
additional logic in the method while keeping the actual implementation hidden.
Does property syntax provide advantages similar to method syntax?

 

[Arne Vajhøj]

What is the advantage of language support for a property with "dot-foo"
syntax compared to a public member Java-style?

Currently Java supports having properties with a dot syntax by dint of
public instance variables, something that is conventionally regarded as
anathema. The common excuse given for turning those into get/set methods
is to allow additional logic in the method while keeping the actual
implementation hidden. Does property syntax provide advantages similar
to method syntax?

A property is a method. Just with a different syntax.

Arne