Skip to main content

Java7 anti-features

41 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24
Points: 0

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02
Points: 0

> > > I have quite a few internal cases which are
> > similar
> > > to ANT tasks. I only quoted ANT tasks because
> that
> > is
> > > a publicly visible use.
> >
> > Okay, but in any of these cases couldn't you
> > you always just expose the fields as public?
>
> I have quite a few cases of read only properties ---
> the implementing class can change the value but other
> classes can only read it.

The proposals I've seen don't cover readonly and writeonly properties (see my earlier post) so wouldn't help you.

leouser
Offline
Joined: 2005-12-12
Points: 0

@jwenting

I hope multiple inheritence never happens. Now a Mixin may be useful. Im looking at a hierarchy where everything derives from a mother object. That's fine but its a real pain to extend from any other base. Changing the mother class into a interface and having the subclasses implement that would work but its a chore to implement the methods(there's alot of them). Just being able to dump the central functionality easily into any class would simplify this greatly.

Im not particularly keen on properties at this point either. It does seem we are introducing a keyword just to autogenerate 1 line getters and setters. Function pointers I may find useful.

leouser

cowwoc
Offline
Joined: 2003-08-24
Points: 0

jwenting,

"it depends". I am personally in favor of embedding metadata alongside JPA code (whether through annotations or other mechanisms that provide compile-time checking) because:

1) Related information is stored close together so it is easier to do sanity-checks.

2) This configuration almost never changes so there is no harm in requiring a code recompile for a configuration change. External configuration files are only really useful if you plan on changing the configuration on a fairly routine basis.

I am personally in favor of a limited use of annotations, just like I am in favor of a limited use of operator overloading. I don't like the idea of any average joe being able to declare either, but I like the idea of well-thought-out operators and annotations being bundled with the Java API across releases. For example, String ships with a + operator in Java and that's fine with me.

On the topic of people pushing for features that don't really make sense, I think I was as guilty of that sort of thing a few months ago before I read "Effective Java". It made me realize some of the Java design decisions and why they make sense. I believe if more people read this book we'd have more agreement over the direction we are going. I think most Java developers aren't bad people, they simply don't know about these things :)

Gili

mhall
Offline
Joined: 2003-06-15
Points: 0

> Well, from my experiences, Java assignment can fail,
> and throws an exception in anytime....

I believe here you are confusing evaluation and assignment. I believe the original poster was correct that assignment can not fail, but evaluation of the value to be assigned can fail.

> [code]
> class Foo {
> public Foo() throws IOException{
> xxxxx
> }
>
> /*somewhere else...*/
> Foo f = new Foo(); /* this assignment will
> fail.....*/
> [/code]

Here, assigning an instance of Foo is not what fails, is it the instantiation of a new Foo object that fails. In other words, the exception is thrown before assignment is attempted.

> or
> [code]
> /*somewhere else again...*/
>
> public String getFoo() {
> throw new IllegalArgumentException();
> }
>
> public void run() {
> String iWantFoo = getFoo(); /* fail again...*/
> }
> [/code]

Again, the evaluation of getFoo() throws an exception before the assignment of it's return value to iWantFoo is even attempted.

> or
> [code]
> int[] ay = new int[0];
> ay[3] = 10; /*who say that assignment is always
> success?*/
> [/code]

This is the only example so far that seems to break the rule. However, if you think of an array not as an individual variable, but as a numbered collection of individual variables, then this is like saying:
[code]
int ay0 = 0;
ay3 = 10;
[/code]

Which of course fails because ay3 is an undeclared variable. In the same way, ay[3] is undeclared, and so you cannot assign anything to it. The only difference is that using ay3 is caught at compile time.

So perhaps we can clarify by saying that in Java, assignment of a value to a declared variable can not fail.

mthornton
Offline
Joined: 2003-06-10
Points: 0

> I believe here you are confusing evaluation and
> assignment. I believe the original poster was
> correct that assignment can not fail, but evaluation
> of the value to be assigned can fail.

Assignment to an array element can fail.

Object[] x = new String[10];

...

x[0] = new Integer(1);

cowwoc
Offline
Joined: 2003-08-24
Points: 0

On the topic of http://weblogs.java.net/blog/cayhorstmann/archive/2007/01/arrows_in_the_...

I feel that's one of the original problems in Hibernate that got inherited into EJB3. Using these technologies ends up utterly destroying any well designed API. I think people needs to separate the two use-cases: an API for end-users and an API for EJB3 (that's what super-packages are probably going to fix for JDK7).

EJB3 interfaces essentially map object state to relational databases and back again. This mapping detail should ideally be hidden from end-users but unfortunately this isn't the case today. I have some ideas on how to fix this but that's outside the scope of this discussion.

Since EJB3 tends to need very boring boilerplate code, just use any decent IDE which will auto-generate this for you. This is technology that exists *today* for free. In my view, the problem is EJB3, not Java :) and hopefully this API pollution problem will go away in JDK7 with super-packages.

Gili

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Remi,

Effective C++ points out that the benefit of accessors methods is that you can replace a class field with a computed value in the future. Consider having a List of integers with a field "averageSoFar". You could change this from a field to a computed value from one release to another without breaking backwards compatibility, whereas language-level property support will not allow this (or at least it won't make this as obvious).

Gili

jwenting
Offline
Joined: 2003-12-02
Points: 0

> Remi,
>
> Effective C++ points out that the benefit of
> of accessors methods is that you can replace a class
> field with a computed value in the future. Consider
> having a List of integers with a field
> "averageSoFar". You could change this from a field to
> a computed value from one release to another without
> breaking backwards compatibility, whereas
> language-level property support will not allow this
> (or at least it won't make this as obvious).
>
> Gili

And properties won't do that, certainly not in any of the "proposals" I've seen so far, in that they use the returntype of the datamember as their type.
You can't therefore have a getter and setter returning a long based on a datamember that's of some other type (or doesn't even exist).

cowwoc
Offline
Joined: 2003-08-24
Points: 0

>And properties won't do that, certainly not in any of the
>"proposals" I've seen so far, in that they use the
>returntype of the datamember as their type.

Fair enough, but does it *ever* make sense to generate setter methods that do not throw exceptions for invalid input values? I have also seen cases where invoking getter methods throws InvalidStateException if the object has been disposed, etc.

The property feature will not give you this, nor will it allow you to add new exceptions after the fact (you'll be breaking the object contract if you do). So really, how is it ever practical to use this feature?

> hate writing getters and setters. My IDE generates them
> for me, sure, but I even hate seeing them inside my
> classes or even thinking about them.

That's because like I wrote above, having a whole bunch of accessor methods is fundamentally bad design to begin with. No one (not the developer, nor the user) want to see this kind of design. The only reason we are even talking about this is because Visual GUI designers and JPA require JavaBeans. Now, there is nothing wrong with JavaBeans or these frameworks but the API they require is not meant for human beings. You're not *supposed* to like seeing a whole bunch of accessor methods. You're not *supposed* to stuff tons of accessor methods into your public API. Why can't you just generate JavaBeans once using your IDE and move on with your life? You should never see this code again (how often does your database mapping ever change?). If you expose this code from your end-user API then you are doing something fundamentally wrong.

From a design point of view, both GUI editors and JPA essentially ask you to provide a whole bunch of public fields that they can manipulate directly. This should set off a whole bunch of red lights in the back of your head. This is a flaw in *their* design, not the Java language.

Gili

jwenting
Offline
Joined: 2003-12-02
Points: 0

> >And properties won't do that, certainly not in any
> of the
> >"proposals" I've seen so far, in that they use the
> >returntype of the datamember as their type.
>
> Fair enough, but does it *ever* make sense to
> generate setter methods that do not throw exceptions
> for invalid input values? I have also seen cases
> where invoking getter methods throws
> InvalidStateException if the object has been
> disposed, etc.
>

It does.
Say you have a field that's a Class1 and need to change it internally to a Class2 which is a class containing a Class1 member (or fields that can be mapped to a Class1 instance).
You can't change the public API so you must leave the setter to take a Class1 argument (and a getter to return it).
You no longer have any data member of Class1, and if you do it has a different name.
Properties as proposed would have your entire public API break instantly.

> The property feature will not give you this, nor will
> it allow you to add new exceptions after the fact
> (you'll be breaking the object contract if you do).
> So really, how is it ever practical to use this
> feature?
>

The only place where properties are of any value is in GUI builders where they can be used to make the code for propertysheets a bit easier to write.
As those effectively only take primitive and string arguments there's hardly ever a problem with complex returntypes and arguments changing datatype between iterations.

So the entire idea is effectively only really applicable to a very small niche field (mainly people creating beans for inclusion in GUI builders).
Yet it will be heavily abused by others who don't understand the implications, causing what essentially amounts to exposing private fields as public and thus de-facto breaking encapsulation.

ilazarte
Offline
Joined: 2005-11-28
Points: 0

if you use get/set Class1, and internally Class2, your public api will be broken because it is now it is returning Class2. if it isn't returning Class2, you didn't actually need that implementation to begin with, so that "issue" is moot.

99.9999% of the time NOBODY changes a private simple member field without breaking the public api. these are simple data holders not services or anything remotely resembling use-casey classes.

ivory tower language "purists" object to them in order to justify their paychecks..

jwenting
Offline
Joined: 2003-12-02
Points: 0

no, your getter and setter return a subset of the state.
The private API doesn't change, but the internal state increases in scope.
That happens more frequently, and would be impossible with properties, certainly with properties that are bound to datamembers as they are in the standing "proposals".
If you change the idea to have a property be something more akin to what Delphi and C# use, a definition of a set of public getter and setter methods to be accessed through a field-like syntax, that problem would go away as the public API wouldn't be hardwired to the internal state.

So you'd get something like
[code]
private Foo fooVal;
public property Foo foo {write:setFoo(Foo foo) read:getFoo()};

public void setFoo(Foo foo) {this.fooVal = foo;}
public Foo getFoo() {return fooVal;}
[/code]

which is pretty similar to the way Delphi does things.
I could live with the getter and setter implementations being generated if they're not provided, but being able to define that either read or write access is disallowed is crucial.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Guys,

Does anyone here want this properties feature for anything except GUI editors and EJB3? You do realize that in EJB3 you can access the fields directly, right? In that case there is absolutely no need to generate getter/setters at all if you are sure (as you claim) that all you want is a simple accessor. I believe most GUI editors support accessing fields directly too.

So I'll ask again, does anyone have a use-case outside EJB3 and GUI editors?

Gili

mthornton
Offline
Joined: 2003-06-10
Points: 0

> So I'll ask again, does anyone have a use-case
> ase outside EJB3 and GUI editors?

ANT tasks use the beans property convention for attributes.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> > So I'll ask again, does anyone have a use-case
> > ase outside EJB3 and GUI editors?
>
> ANT tasks use the beans property convention for
> attributes.

And how often do developers write Ant tasks? This covers under 1% of the entire developer population. You'd be better off modifying Ant to look for public fields if the accessor methods are missing. It's much cheaper modifying such tools to just get at fields directly if all you want is are pass-through accessors.

Gili

mthornton
Offline
Joined: 2003-06-10
Points: 0

> > ANT tasks use the beans property convention for
> > attributes.
>
> And how often do developers write Ant tasks? This
> his covers under 1% of the entire developer
> population.

I have quite a few internal cases which are similar to ANT tasks. I only quoted ANT tasks because that is a publicly visible use.

> missing. It's much cheaper modifying such tools to
> just get at fields directly if all you want is are
> pass-through accessors.
And what about the common GUI need for bound properties (i.e. notification of changes).

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> I have quite a few internal cases which are similar
> to ANT tasks. I only quoted ANT tasks because that is
> a publicly visible use.

Okay, but in any of these cases couldn't you always just expose the fields as public?

> And what about the common GUI need for bound
> properties (i.e. notification of changes).

That is a totally different use-case which I probably agree with you on. Are you referring to the fact that you want to bind a property to a callback function such that when the property changes you want the callback invoked? So I am guessing you are saying that currently you bind to properties using Strings which is bad because you don't have compile-time checking but if we had language support we could provide compile-time checking. I personally support adding compile-time checking for this sort of thing, I'm just not sure how yet. Maybe we could borrow from the "foo.class" syntax and introduce "age.method" or "age.field" which would get substituted by a Method or Field at compile-time with all the appropriate compile-time checking. It would certainly be consistent with other Java syntax, easy to implement on the compiler-level and it would not modify the bytecode format at all. The downside is that "method" and "field" become reserved words in the language and any old code that uses them for variable or method names would break. Then again, Sun did something similar for "enum" so it wouldn't necessarily be the end of the world.

Gili

mthornton
Offline
Joined: 2003-06-10
Points: 0

> > I have quite a few internal cases which are
> similar
> > to ANT tasks. I only quoted ANT tasks because that
> is
> > a publicly visible use.
>
> Okay, but in any of these cases couldn't you
> you always just expose the fields as public?

I have quite a few cases of read only properties --- the implementing class can change the value but other classes can only read it.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

You've got me then :)

I'm still advocating that (generally speaking) JavaBeans clients use public fields or use an IDE to generate the accessors once and go on with their lives. In most cases, you'll never see that code again.

In your case of read-only properties I would use the IDE to generate only the getters. I guess if you don't agree on this point we'll have to agree to disagree :) Thank for providing use-cases though, it helped me understand.

Gili

mthornton
Offline
Joined: 2003-06-10
Points: 0

I'm not convinced of the case for 'native' properties either, but you asked for use cases ...

forax
Offline
Joined: 2004-10-07
Points: 0

> > You don't see why property is needed,
> > read my blog:
>
> > Rémi
>
> Property is NOT needed, except by feature junkies who
> want it "because C# has it".

???, any developers knows what a property is, or at least
have a general idea about properties.
I don't see why Java could not be have a native support
of this feature if it can remove boilerplate codes,
i.e. getter and setter that just access to a field.
C# doesn't matter with that observation.

> Java (and many many other languages) has done very
> well without it for over a decade.

yes and no, it's like foreach, you can write a code
without a foreach loop but it is less readable.

>
> This tendency to add everything and the kitchen sink
> to the language is destroying the language.
> Whether Sun intends to do that or is just acting
> stupid in a marketing drivel induced haze I don't
> know, but my trust in them to do what's good for the
> language and the platform has just about evaporated.

I am not a SUN employee and i have already a day job.
Java is Open Source, at least its compiler,
so i can patch it if i want.

I hope properties will be included in the language but
if the community says no or anyone found a good reason
to not have them, i will not die.

Rémi

jwenting
Offline
Joined: 2003-12-02
Points: 0

> On the topic of the property language support, I
> thought one of the main benefits of encapsulation is
> that you could change the underlying variable names
> without breaks the visible API. Isn't this proposal
> violating one of the basic tenants of Object-Oriented
> Programming?
>
> Gili

It is, but since when has that stopped the idiots writing up such proposals?
Embedding metadata in code is also against everything best practice tells us to do, yet annotations do essentially that.
A decade ago it was decided that operator overloading and function pointers were BAD, yet both seem set to make their way into Java.
There's screaming for multiple inheritence at class level, another thing that's been recognised as a Bad Thing. Luckily that's not made it (yet), probably because noone has taken the time to write up a nice sounding proposal that will sway the marketing guys who now decide on what the language will be.

vhi
Offline
Joined: 2004-10-11
Points: 0

>> Embedding metadata in code is also against everything best practice tells us to do, yet annotations do essentially that.

It depends on what you call metadata. For me, even the access modifiers (private, public) are metadata. Annotations allow us to put metadata information where it belongs. If it describes a method, then we have method level metadata etc.

>> A decade ago it was decided that operator overloading and function pointers were BAD, yet both seem set to make their way into Java.

Do you think that "+" operator overloading in String was a bad idea? I think operator overloading could be included, but allowed *only within* java.lang packages. The reason operator overloading in C++ is bad was because it allowed any random interpretations of operators, which usually went against math conventions.
Operator overloading brings clarity to scientific computing.

>> Isn't this proposal
> violating one of the basic tenants of Object-Oriented
> Programming?

The *proposal* is NOT breaking basic tenants of OO. YOU as a developer/designer are. What to properly encapsulate is not decided by the *language*. It is always a *design* decision. So if you have bad designers, they will just add getters and setters (or make fields public), regardless of what the language features are. It is not a language problem, it is a *knowledge* problem.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

hey guys

I wonder why everyone in the java community is acting obliveous to what is going on in .NET community regarding the LINQ project

its such a hell of a great feature that should be considered for the JAVA ........ it saves alot of time

I have seen the SAFFRON project which is sort of similar stuff in java. But its hard to install and configure plus it needs to be something standard to be practical
check it:
http://sourceforge.net/projects/saffron/X

I have created other forum topic specific for this topic
hope you guys will contribute ....... java community should hear a loud voice before they start moving their asses

here is the other forum
http://forums.java.net/jive/thread.jspa?threadID=21183&tstart=15

oakidoaki
Offline
Joined: 2004-11-30
Points: 0

The whole point of properties is to make the developers life easier by cleaning up the code and ridding him of repetitive typing. I see nothing wrong with that. I hate writing getters and setters. My IDE generates them for me, sure, but I even hate seeing them inside my classes or even thinking about them. Some variables are just made for getters and setters. Knowing this, why not just declare them "properties" and forget about them?

Whats wrong with typing (for example)

private property int x;

with the language automatically providing accessors? Like this, just one look and its cristal clear that this is a variable that is supposed to be accessed by some kind of get/set mechanism.

The way it is done now, you have no way of telling if a variable is a property or if its just a "normal" variable used for the internal workings of your class, without scanning your class for getters and setters, which also clutter up your code.

Properties, implemented correctly, would be nice.

prunge
Offline
Joined: 2004-05-06
Points: 0

This property proposal is actually one of the only ones I'm not too much against.

If property support was introduced, I'd like a property to act exactly the same as if you wrote the getters and setters yourself. So the only thing that would change is you would end up writing less code.

Yes, most current IDEs generate the getter/setter code for you - but any time you generate code there is more code for you to maintain. Things can also go wrong - e.g. change the field name without changing the getter/setter method names, or when changing names you can type one of the letters in the wrong case. Less generated code is better.

Properties couldn't do anything special, such as null or value range checking. OK, fair enough, in this case write your own setter method.

So is the introduction of a new language feature for properties worth it? What percentage of our code is getters/setters? Maybe it'd be worth someone coming up with a few statistics for this for a few different types of applications.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> This property proposal is actually one of the only
> ones I'm not too much against.
>
> If property support was introduced, I'd like a
> property to act exactly the same as if you wrote the
> getters and setters yourself. So the only thing that
> would change is you would end up writing less code.
>
> Less generated code is better.

Yes, less is better, but only if it makes sense. IDEs do a wonderful job of generating accessor methods and renaming them very easily. As I have said before, if you have tons of accessor methods it is very likely there is something wrong with the design of your class. Now, it is your choice to do something wrong, but it should be Java's job to make it difficult to do the wrong thing and easier to do the right thing.

> Properties couldn't do anything special, such as null
> or value range checking. OK, fair enough, in this
> case write your own setter method.

That's one of the major contention points for me. I am fairly sure someone will design a class using the built-in accessor methods first then at a later time decide they want to add null or range checking only to discover that it is no longer possible to do so without breaking the object contract. By forcing users to write the accessors themselves it is more explicit that they should add all the necessary exceptions ahead of time. Advocates of this feature argue that we're simply hiding trivial code but the fact of the matter is that I don't think the trivial code they want to generate exists in real-life applications. Anyone who has accessors that don't throw some exception for invalid arguments is simply not realistic. I don't see a general way to solve this problem. Developers simply need to write code. Computers won't do this for us :)

> So is the introduction of a new language feature for
> properties worth it? What percentage of our code is
> getters/setters? Maybe it'd be worth someone coming
> up with a few statistics for this for a few different
> types of applications.

Well, the vast majority of developers writing JavaBean code are likely to have tons of accessors but how often is JavaBeans used in the industry for APIs that are exposed to end-users? If you're writing code for Hibernate, that is one thing. If you're writing code for human beings, that's another thing. Just because Hibernate and GUI designers want the JavaBean convention does not mean that user-oriented APIs should use the same style; in fact doing so is almost always a design flaw.

If you guys are trying to make it easier to write GUI or Hibernate code, then fine let's go find a way to improve these frameworks but don't change the entire language around it. Also consider the fact that for GUIs and Hibernate you almost never need to modify the accessors once they're autogenerated by the IDE. You do it once and you're done. I don't think this justifies a language-level construct.

Gili

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I wanted to proposed a twist on some proposals going around. Please give it some thought and tell me what you think. I'm still not sure whether I am for or against it, but it's worth considering. It goes something like this...

If a user invokes:

[code]MyClass.getMyField();[/code] or
[code]MyClass.setMyField(5);[/code]

and such a method does not exist, the language could look for "myField" as a public field. I believe this approach has the following advantages over the other ideas that are floating around:

- no new language operators to learn about (evil arrows)

- it is more obvious that methods may throw exceptions than it is that this code might: [code]MyClass.MyField = 5;[/code]

Gili

fcmmok
Offline
Joined: 2005-05-12
Points: 0

HI,

I saw many people against the foo.bar or foo->bar way to access the Java(tm) Property just bcuz they dun want the assignment fail:

"Java assignment can never throw an exception"

Well, from my experiences, Java assignment can fail, and throws an exception in anytime....
[code]
class Foo {
public Foo() throws IOException{
xxxxx
}

/*somewhere else...*/
Foo f = new Foo(); /* this assignment will fail.....*/
[/code]
or
[code]
/*somewhere else again...*/

public String getFoo() {
throw new IllegalArgumentException();
}

public void run() {
String iWantFoo = getFoo(); /* fail again...*/
}
[/code]
or
[code]
int[] ay = new int[0];
ay[3] = 10; /*who say that assignment is always success?*/
[/code]
To conclude, Java assignment will not fail only when u assign a "CONSTANT" to a variable and u is lucky enough(I means u is professional enough, actually).
So, it is not a problem that foo.bar = 10 or foo->bar = 10 or foo->bar = cin.readLine() will fail as they are expected to be fail..

Meanwhile, can anyone tell me the harms of assignment fail or throwing an exception in the case below:
[code]
String line = thisIsABufferedReaderObject.readLine();
//readLine() may throw IOException, so what ...?
[/code]

cowwoc
Offline
Joined: 2003-08-24
Points: 0

fcmmok,

You bring up good points regarding assignments but I still think you're wrong. In every single one of your examples, it isn't the assignment that is failing but rather the thing that happens *before* assignment. My point was that if I say:

myObject.myProperty = 5;

I wouldn't expect it to fail. Especially if (for example) myProperty was a simple int primitive in the past and it changed into some complex array structure in the future.

The point of encapsulation is that regardless of the underlying implementation today or tomorrow I should be able to expect the same behavior (otherwise I broke backwards compatibility). With the proposed property feature if I ever move from a public field to a getter/setter-backed field then all of a sudden it is possible for the operation to throw exceptions whereas it was impossible in the past. You just broke the object contract.

If I understand it correctly, users are asking for the ability to move from public fields to accessor-backed fields seamlessly without having to change client code, but the only way you can do that is if the resulting accessors do not throw any exceptions and the only way you can do that is if you construct boilerplate accessors that do nothing except get/set the underlying values. And in such a case, IDEs already do this sort of thing for you today without encouraging bad/dangerous behavior which the language construct which encourage. People might not realize they are breaking the object contract by introducing these new exceptions. It's definitely no longer obvious from the client-code as it is with formal accessor methods.

Final point: I am in the middle of reading Effective C++. One point he makes in favor of formal accessors is that of consistency. Users know that anytime they want to access the insides of an object they have to invoke a method. They don't wonder whether the underlying value is an actual field or a computed value (in fact, this implementation detail may change across releases). From their point of view they are always invoking a method and getting back a result regardless of what happens under the hood. You couldn't provide this level of flexibility with the language-level property construct.

Gili

meshpaul
Offline
Joined: 2005-02-07
Points: 0

I agree, If this does not by us anything. I would reather see JDK7 team concentrate on other things.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Remi and others. Please explain to me because I honestly want to understand:

What do you guys want/expect from property language support?

1) The ability to access a public field or getter/setter property using the same class.field syntax?

2) The ability to reference a property as a first-class citizen, similar to pointer to a field in C++? I believe this is somewhat related to the request for the ability to reference methods in Java. So I call this the "callback proposal". The benefit is that you get compile-time checking that you are binding to the correct method or field type as opposed to storing a string name and using reflection at runtime to look it up.

3) Auto-generation of boilerplate code for getter/setter methods.

4) Other ... if there is more please mention it.

Assuming I understand all the proposals correctly (and it is possible I do not) I am personally against all of them except #3. I personally see value in compile-time checking for referencing methods or fields. I will tell you why I am against all the other points:

1) I believe this amounts to providing operator overloading for "." or "->" in the Java language. Classically a Java assignment can never throw an exception but in this new proposal (which invokes a setter under the hood) you might end up with an unexpected exception. I see minimal or no readability gain to this new syntax and a lot of potential harm.

3) Generally speaking, exposing all properties using getter/setters is a bad idea because it breaks encapsulation. If writing tons of getter/setters is difficult that is actually a good thing in my view because all good APIs aim to make incorrect behavior hard to do. "Effective Java" (http://java.sun.com/docs/books/effective/) explains this point quite well.

In my experience as a 10+ year programmer, you almost never have a whole bunch of simple getter/setter methods that do nothing but expose your properties. And if you do, something is fundamentally wrong with your design because you're probably breaking encapsulation (as mentioned above) without a good reason.

Do we simply hold a different opinion or am I missing something about the proposals?

Thank you,
Gili

cowwoc
Offline
Joined: 2003-08-24
Points: 0

On the topic of the property language support, I thought one of the main benefits of encapsulation is that you could change the underlying variable names without breaks the visible API. Isn't this proposal violating one of the basic tenants of Object-Oriented Programming?

Gili

forax
Offline
Joined: 2004-10-07
Points: 0

That is why the proposal defines to kind of properties :
- simple property that is a field with getter and setter
- abstract property that let you write getter
and setter.

The idea is that you replace one property by the other
without breaking binary compatibility.

Rémi

jwenting
Offline
Joined: 2003-12-02
Points: 0

> That is why the proposal defines to kind of
> properties :
> - simple property that is a field with getter and
> setter
> - abstract property that let you write getter
> and setter.
>

Far easier to just define everything as public access. No need for new syntax, language changes, and whatnot.
You're just putting a thin veneer around public access to member variables with this entire lunatic idea after all, but of course "C# has it so it must be perfect".

When will kids learn to leave well enough alone and use what they have rather than ruining it by adding ill tought out things just "because XXXXX has it"?

cobrien
Offline
Joined: 2004-06-09
Points: 0

interfaces don't have fields, and you can't override access to a field.

Python lets you implement getProperty()/setProperty() (I think that's the name) so that foo.bar can execute any method you want. It's pretty handy. I agree that it's just synatactic sugar though.

mklemm
Offline
Joined: 2005-03-29
Points: 0

I partly agree with the points you make...

Totally agreed on the "property" issue.

Method references could be useful, but should be integrated into the language in a more consistent way, and with a consistent syntax similar to that used by C/C++ for pointers to methods. That would include introducing a "typedef"-like alias mechanism to make such a thing handleable by developers. You could then say:

class A {
public typedef int MyMethodType(int, String);

public int methodWithMethodArg(MyMethodType method) {
return method(42, "Hellloworld");
}
}

class B {

private int myMethod(int number, String s) {
// Do something with number and s
// return something
}

public static void main(String[] srgs) {
A instance = new A();
System.out.println(instance.methodWithMethodArg( myMethod ));
}
}
Instead of the native XML support depicted in the presentation I would prefer a generalized implementation of something like the JSP-Syntax into the core Javac, i.e. a syntax for mixing java code and other text. Based on this, you could solve the inline XML problem as well as things like SQLJ or whatever you want...

I think many JSRs are just too specialized, and too few people are trying to focus on the big picture keeping minimality and consistency across the platform...

Message was edited by: mklemm

Message was edited by: mklemm

forax
Offline
Joined: 2004-10-07
Points: 0

You don't see why property is needed,
read my blog:
http://weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html

Rémi

jwenting
Offline
Joined: 2003-12-02
Points: 0

> You don't see why property is needed,
> read my blog:

> Rémi

Property is NOT needed, except by feature junkies who want it "because C# has it".
Java (and many many other languages) has done very well without it for over a decade.

This tendency to add everything and the kitchen sink to the language is destroying the language.
Whether Sun intends to do that or is just acting stupid in a marketing drivel induced haze I don't know, but my trust in them to do what's good for the language and the platform has just about evaporated.

mklemm
Offline
Joined: 2005-03-29
Points: 0

... And what is proposed here is completely different from the property support in C#.

C# only has a different syntax, but essentially the same semantics as in current java, for property definition. The one difference is the syntactical grouping of the getter and setter for one property in the same place in the source code, which is IMHO a good idea. The other difference is the call syntax for properties so the property can be accessed like a public instance variable, which is pretty ugly, but MS has advertised to do so since the first versions of their MFC libraries...

But, even in C#, nothing is generated by the compiler automatically, as proposed here. Even there, a property remains to be an instance variable for which you have to provide your hand-written get and set methods...

forax
Offline
Joined: 2004-10-07
Points: 0

I've decided to generate getter and setter because what i want with a property is the ability to access to it
in the same way (in the source and in the bytecode) whatsoever its representation
(a field or a couple of getter and setter).

C# have a property mecanism but it doesn't match with that requirement.

Rémi