Java Programming

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Property Support in Java

807607Jan 15 2007 — edited Jan 15 2007

I wrote the following comment after reading this:

http://www.javalobby.org/java/forums/t88090.html

So, if the syntax to access properties in Java are going to be like this:

customer->name

instead of this:

customer.name

I would say that Java did it again: it wasn't enough libraries like
Date/Calendar, Swing, Java Mail, EJB (before 3.0) and others be written the way
they were, very complicated; they could complicate even the use of properties in
the language in the name of the so called 'flexibility' that treat the most
unusual scenario so important or even more important than the scenario that is
used in 99% of the cases.

How come language designers make its users type '->' (two characters instead of
just one) everywhere to access a property just because they want the user to
have the hability to expose a field with the same name of the property, and for
this field, that is a lot less commom than a property, have the '.' (dot)
access? If the user wants to make a field public he will give this field a name
that doesn't conflict with the name of any property in the interface of the
class. This is the right solution. And about the private fields that serve to
hold the values of properties, I'm sure that no one won't care to prefix these
fields with '_' or 'f' or whatever they want not to conflict with the property
name, for the clients of the class (that are the reason why properties exist) to
have the ease of use to access properties the second way showed above, with the
dot notation.

Come on, if the syntax to access a method of a class is this:

dialog.show()

the syntax to access a property of a class should be like this too:

dialog.title
dialog.title = "Customers"

This is intuitive, consistent with the method syntax, productive, clear,
elegant, easy to type, less error prone. This is so right that I don't know how
someone can think something different than this. All other languages: C#,
Delphi, Ruby, Eiffel, JavaScript, etc. could not be wrong. They users haven't
complained about the way they implemented properties. So, why Java should come
up with another syntax for properties instead of the one that we have seen
until today? Just to complicate users' life, taking their productive away,
in the name of a 'flexibility' that is not worth its weight, that doesn't
even exist? If properties are going to be implemented with '->' it will be
easier for the implementors of a class, but it will be a nightmare for the
users of the class, that are the majority of people and the reason why
properties exist. The implementors of a class have to program for the users of
a class, not for themselves. The same is true for language designers; they
should have as the main goal the users of classes, not their implementors.

I see that many people that don't use Java want to use it, but people that
design the Java language and its APIs keep making them away from it,
scaring them.

Getters and setters are one of the most painful things of Java. If they want to
add property support to the language now, don't do it 'the Java way',
do it the right way, do it with the '.' (dot) notation.

Marcos

807607

You can access properties using customer.name. just declare the scope of the property as public.

>

Getters and setters are one of the most painful
things of Java. If they want to
add property support to the language now, don't do it
'the Java way',
do it the right way, do it with the '.' (dot)
notation.

Really?

Ted.

807607

Really?

Yes, really!

Marcos

mlk

You can access properties using customer.name.
just declare the scope of the property as public.

Properties are not member variables, but methods, wrapped up to look like variables. Just a way of doing get/set without the get and set in the using class code.

Personally I dislike them. More muddy water to wade through.

807607

Personally I dislike them. More muddy water to wade
through.

Amen brother.

807607

Properties are not member variables, but methods,
wrapped up to look like variables. Just a way of
doing get/set without the get and set in the using
class code.

I agree with your definition of properties.

>

Personally I dislike them. More muddy water to wade
through.

I think that more muddy water to wade through is this:

customer.getAddress().setStreet(txtStreet.getText());

not this:

customer.address.street = txtStreet.text;

Which one is easier to read and to maintain in your opinion?

Marcos

807607

Which one is easier to read and to maintain in your opinion?

The difference in reading imho is inferior to the amount of ambiguity that comes with it. Actually I hate VB code for mixing up the syntax for field access and method invocation. Also I'd hate an "->" operation. Seems like most language features added since 1.4 have been introduced for people who are too lazy for both typing and using a code generator ...

mlk

Which one tells me I'm calling a method?

If properties are added to Java, then I think my prefrence is for

name->first

as a compiler-only feature, which is compiled to

name.[g|s]etFirst

As this
a) is clear that it is a method call, not a variable.
b) requires no retro-fitting to old classes.
c) I can ignore properties.

Message was edited by:
mlk

807607

The difference in reading imho is inferior to the
amount of ambiguity that comes with it.

I don't agree. If properties were present in Java since its beginning no one would be complaining now about it and if someone proposed for it to be replace be getters and setters everyone would suggest him a sanity check.

Seems like most language features added
since 1.4 have been introduced for people who are too
lazy for both typing and using a code generator ...

I language should not depend on code generators.

Marcos

807607

Which one is easier to read and to maintain in your opinion?

honestly, the first one.

the problem is that you don't know what the property assignment will do; you don't know if it's a property without looking at the code.

trust me, from many many years of using c# you will realise properties aren't that great. they mostly create confusion. some benefits for sure; like when you don't even use a member variable to save the values into (maybe you use a session/viewstate instead), but overall i could do without them.

807607

Which one tells me I'm calling a method?

But that's not what matter. You know that properties call methods inside it, so why should you care? If your routine is time consuming, make it a method, if not, generally it should be a property. Why should we be accessing internal fields with public methods when the methods could be internal and the interface of a class be clean for us with this. Also, only with methods many times we don't know if that method is just acting like a property or not. Properties are more intuitive.

Marcos

791266

And about the private fields that serve to
hold the values of properties, I'm sure that
no one won't care to prefix these
fields with '_' or 'f' or whatever they want not to conflict with
the property name

I would care. I hate prefixes.

jwenting

You can access properties using customer.name.
just declare the scope of the property as public.

Properties are not member variables, but methods,
wrapped up to look like variables. Just a way of
doing get/set without the get and set in the using
class code.

In all the proposals I've seen they're effectively no more than another means of declaring something public.
The compiler will make a naked getter and setter for you with nothing in the way of bounds checking or whatever, and that's it.
You can't even declare something to be read-only (for example).

Personally I dislike them. More muddy water to wade
through.

Yup, and more to confuse people. You'd end up calling a method with a call that looks nothing like a method call (or worse, an operator that's really a method call).

Might as well implement full operator overloading and class level multiple inheritance as well.
After all, those are also present in another language and THUS are somthing the just MUST be in Java (using the logic that's used to promote properties, function pointers, and all the other crap).

807607

I don't agree. If properties were present in Java
since its beginning no one would be complaining now
about it and if someone proposed for it to be replace
be getters and setters everyone would suggest him a
sanity check.

Well, your opinion. I prefer to be able to see what's happening from any part of source code and not to have to dig into class for class to find it out.

I language should not depend on code generators.

Of course it shouldn't. But where did I say so? If you hate writing setters/getters, get or write a generator for them. But don't make the language change and force me to understand the resulting syntax. At least it adds no, absolutely no functionality.

It's the same for all this generics stuff: "Oooh, I don't like to type casts and it looks so messy, and I might run into ClassCastExceptions. Let's change the language to something no newbie is able to understand. At least, C++ is sooo cool with its templates, so we should add something that looks similar."

mlk

I would care. I hate prefixes.

The way C# seams to do it (and something I'm not advocating) is first letter in uppercase for the propertiy, while the private is all lower case.

807607

the problem is that you don't know what the property
assignment will do; you don't know if it's a property
without looking at the code.

This is a risk we should consider. But you should agree that in a way designed interface you won't have this doubt. Experient programmers will write methods like methods, not like properties. Beginning programmers will do mistakes, but that's why naming guidelines and conventions exist, to teach them what is right.

807607

Let's change the language to something no newbie is able to
understand.

Properties definitelly are not included in the things to newbies.

807607

I would care. I hate prefixes.

The way C# seams to do it (and something I'm not
advocating) is first letter in uppercase for the
propertiy, while the private is all lower case.

yes. and it is immensly annoying. c#'s whole naming system is wrong and just makes the language confusing to read. you never know what is a static method, etc. worst of all is that, due to the properties and the allowance of putting actual code into them, you never know whether a 'thing' you want to call is a property (Foo.IsValid) or a method (Foo.IsValid()). there really is no consistency.

791266

Let's change the language to something no newbie is

able to

understand.

Properties definitelly are not included in the things
to newbies.

Newbies will use it, and it will lead to code which is hard to maintain and follow. I don't want properties, but would vote for anything which isn't the dot. I would even vote on #

Kaj

807607

Properties definitelly are not included in the things to newbies.

Why not? It's like saying "Generics isn't for newbies ... stay away from java.util.* until you're grown up". Java's learning curve was always steep for newbies, thanks to the rich API that's delivered. Now it becomes more and more steep thanks to language features that are merely shortcuts for typing, nothing more.

807607

I would care. I hate prefixes.

It's better to type prefixes instead of the clients of your class type '->' to access a property everywhere. Classes are made for users, not for implementors.

807607

Newbies will use it, and it will lead to code which
is hard to maintain and follow.

I agree, but will this code be made for the highly succesfull APIs that you use, made for experient programmers? No, it won't. You will only have access to code that is not hard to maintain or follow.

791266

I would care. I hate prefixes.

It's better to type prefixes instead of the clients
of your class type '->' to access a property
everywhere. Classes are made for users, not for
implementors.

Who do you think the user of my classes is?

I as a user of classes want to type anything except for "dot" for properties. I don't want properties to be confused with attributes.

Kaj

807607

I agree, but will this code be made for the highly
succesfull APIs that you use, made for experient
programmers? No, it won't. You will only have access
to code that is not hard to maintain or follow.

Disagree. Add more "features" to a language and you'll find more "creative minds" who try to abuse 'em. See thedailywtf.com for some examples. Imho, the clearer a language is and the fewer ways there are for doing the same thing, the less shit can happen.

807607

I don't want properties to be confused with attributes.

In the majority of cases you won't be exposing attributes. They're not made to be exposed.

791266

I would care. I hate prefixes.

It's better to type prefixes instead of the clients
of your class type '->' to access a property
everywhere. Classes are made for users, not for
implementors.

And no, it's not better to type prefixes. Prefixes can't be checked by a compiler, and will not be followed/used by all programmers.

807607

Imho, the clearer a language is and the fewer ways there are
for doing the same thing, the less shit can
happen.

I know this, but I'm sure that properties won't take any language to the messy level. They are not so evil like many people say.

mlk

I don't want properties to be confused with

attributes.

In the majority of cases you won't be exposing
attributes. They're not made to be exposed.

Sorry, confused. When will you use properties, over a method to do something other than expose an attribute. That is what every example I've seen in my short jollies into XNA have been doing.

Unless I have a different defination of an "attribute" than you.

791266

Newbies will use it, and it will lead to code

which

is hard to maintain and follow.

I agree, but will this code be made for the highly
succesfull APIs that you use, made for experient
programmers? No, it won't. You will only have access
to code that is not hard to maintain or follow.

It sounds like you haven't been involved in any larger projects. Is that true? There are many many projects with more than 20 developers and more than 3000 classes. Such code is always hard to maintain, even without properties.

Kaj

807607

I'm sure that properties won't take any language to the messy level. They are not so evil like many people say.

I'm not scared of properties, I'm sure they won't make me stay awake at night. But as you like to make a difference between pro and hobby developers, I could ask the following: who is supposedly in the need of properties and has access to code generation tools, and who gives a damn about properties but needs to learn the whole syntax?

mlk

Imho, the clearer a language is and the fewer ways

there are

for doing the same thing, the less shit can
happen.

I know this, but I'm sure that properties won't take
any language to the messy level. They are not so evil
like many people say.

I'm going to assume you count me as part of the "properties are evil" crowd. Properties (on there own) are not evil. Muddy the water: Yes. Evil: No.

Properties mixed with operator overloading, C# naming standard and collections. Hell yes, that is evil.

807607

Sorry, confused. When will you use properties, over a
method to do something other than expose an
attribute. That is what every example I've seen in my
short jollies into XNA have been doing.

Unless I have a different defination of an
"attribute" than you.

When you said 'attribute' I thought you meant the fields of a class, instance variables.

mlk

When you said 'attribute' I thought you meant the
fields of a class, instance variables.

OK, that is all I have seen Properties do. Expose instance variables. When would you use then then, if not for that?

807607

Who is making all these great language "feature" proposals at all? Are they bored? Are they looking for "cool stuff" to be added? In my Java career, I have experienced neither an epidemic of ClassCastExceptions nor a great loss of time for getter/setter method creation. The problems I'm facing in daily routine have to do with less efficient code, memory consumption, threading issues, and processor load. So I'm happy with any speedup introduced by a new Java release, but I'm also eager to ignore any syntactic sugar that's introduced to make the masses cheer (and seem to try to address common critics from the C#, C++, and PHP crowd).

807607

OK, that is all I have seen Properties do. Expose
instance variables. When would you use then then, if
not for that?

So, you also should not use the new for loop introduced in Java 5.0, because its just a replacement for the iterator, static import, and many other features.
Properties make clean code and simplicity and maintenance matters.

807607

So, you also should not use the new for loop introduced in Java 5.0, because its just a
replacement for the iterator, static import, and many other features.

Not use. That's an exact description for what I do to them.

807607

Will they add personal properties too? I would love to be able to write

public personal property String name;

807607

but I'm also eager to ignore any syntactic sugar that's introduced to
make the masses cheer

I don't consider properties like syntactic sugar. I think they add value to the language. I know many suggestions are just syntactic sugar, but I wouldn't not include properties among them.

mlk

I don't consider properties like syntactic sugar. I
think they add value to the language. I know many
suggestions are just syntactic sugar, but I wouldn't
not include properties among them.

What are they then? What do they add over get/set/is methods (other than a subjective ease of writing/reading?

807607

I think they add value to the language.

Like what? They add nothing I wouldn't have been able to do before.

791266

So, you also should not use the new for loop
introduced in Java 5.0, because its just a
replacement for the iterator, static import, and many
other features.

I don't use static imports (mostly because I don't need them), and we are forbidden to use autoboxing and unboxing in our project (because I said so). Autoboxing and unboxing are evil.

Kaj

807607

What are they then? What do they add over get/set/is
methods (other than a subjective ease of
writing/reading?

As I said this 'subjective ease of writing/reading' matters. Especially reading.

807607

I don't use static imports (mostly because I don't
need them), and we are forbidden to use autoboxing
and unboxing in our project (because I said so).
Autoboxing and unboxing are evil.

They are. And I already hate the day they introduce JDK 5 or higher to my section, cause the very same day, a creative but, uhm, idealistic co-worker is going to clutter all commonly used classes with generic support for no appearent reason and this way open pandora's box.

791266

So, you also should not use the new for loop
introduced in Java 5.0, because its just a
replacement for the iterator

It's not only used with iterators you can use it with arrays as well. The new for loop has benefits, it makes it impossible to mix indices in nested loops.

Kaj

807607

I don't use static imports (mostly because I don't
need them), and we are forbidden to use autoboxing
and unboxing in our project (because I said so).
Autoboxing and unboxing are evil.

They are. And I already hate the day they introduce
JDK 5 or higher to my section, cause the very same
day, a creative but, uhm, idealistic co-worker is
going to clutter all commonly used classes with
generic support for no appearent reason and this way
open pandora's box.

I have to agree that I don't use static import, but I use the new for loop and autoboxing and unboxing.

807607

As I said this 'subjective ease of writing/reading' matters. Especially reading.

What's a property other than a) a private field with getter and setter support or b) a public field? For both cases, there are common means to describe and use them. Why introduce a third way?

mlk

As I said this 'subjective ease of writing/reading'
matters. Especially reading.

So this is syntactic sugar. Not that there is anything wrong with syntactic sugar. Gernerics & the new for loop are great (IMO). But it is just sugar.

Message was edited by:
mlk

798906

The arrow operator is ugly and introducing a keyword called "property" will break about 8 million classes.

807607

As I said this 'subjective ease of

writing/reading'

matters. Especially reading.

So this is syntactic sugar. Not that there is
anything wrong with syntactic sugar. Gernerics & the
new for loop are great (IMO). But it is just sugar.

Message was edited by:
mlk

If something matters it is automatically excluded from the syntactic sugar category.

807607

As I said this 'subjective ease of writing/reading'

matters. Especially reading.

What's a property other than a) a private field with
getter and setter support or b) a public field? For
both cases, there are common means to describe and
use them. Why introduce a third way?

It's because getters and setters are a mistake. They should not even exist from the beggining. There should be only two ways:

1) Properties
2) Public fields

807607

Ok, what about this: as I keep on mistyping String as "Stirng", so I'd like to introduce class aliases. For me it matters, so it's not sugar.

1 - 50

Locked Post

New comments cannot be posted to this locked post.

Locked on Feb 12 2007

Added on Jan 15 2007

151 comments

396 views

Java Programming

Property Support in Java

Comments

Post Details