simplifying use of properties

[kartik]

The change you describe is inherently incompatible, though.

Not if you change reflexive field access to match the hardcoded
equivalent.

In fact, the
VM you describe is fundamentally different and incompatible to the current
JVM.
What you argue for is effectively another language with
wholely different concepts.

I don't think so.

I'll not say that these concepts in themselves
have no merit, but in the Java programming language, they are not
appropriate, since they run against several other principles of the
language's
design.

Like what?

No, you can't. Think about reflexive invocation - Will work with a public
method, will not work with a inaccessable field, and getter/setter pairs.

That's not a problem; I wasn't proposing changing the semantics of the
invokevirtual instruction for somebody to complain that the parallel
using reflection behaves differently from a hardcoded invocation. What
we do need to change is reflexive field access: it should invoke the
getters & setters when the field isn't found. But that's pretty
logical.

This is what i said. Most assume it has to be backed by a field, and if
you use field access syntax, you reinforce that notion.

Maybe, but I still think it's straightforward for novices to
understand that what looks like a field access may be an invocation,
once you explain it to them. There are tougher concepts novices must
understand.

 

[Stefan Schulz]

Like what?

Read the Java Language Specification, the chapters dealing with fields and
methods... you can do a lot to fields you can't do to methods, and vice
versa. The two concepts just don't work interchangably.

For example:

class A {
private int foo = 5;

public int getFoo(){
return foo;
}
}

class B extends A {
public int foo = 2;
}

class C {

public static void main(String [] argv){
A a = new B();
System.out.println(a.foo);
}
}

What should the main print out? My guess would be 5, to remain consistant
with the normal hiding conventions, but it would be a guess.

That's not a problem; I wasn't proposing changing the semantics of the
invokevirtual instruction for somebody to complain that the parallel
using reflection behaves differently from a hardcoded invocation. What
we do need to change is reflexive field access: it should invoke the
getters & setters when the field isn't found. But that's pretty
logical.

And error-prone. I fail to see the logic in your proposal. A field access
is something fundamentally different from a method invocation. With one
you can be sure that the instruction will directly change the object
state with no further side effects. With the other, you invoce a function
that not only can take arbitrarily long, but alos have all kinds of further
effect (even ignoring your original argument).

What's more, you need to constantly worry how actual access happens. After
a time, you tend to just call the accessor, which does all kinds of sanity
checks etc. What if your "property" is in fact backted by an accessible
field,
and you depend on the sanity checks / synchronization / other effects of
the
accessor? Errors waiting to happen.

Maybe, but I still think it's straightforward for novices to
understand that what looks like a field access may be an invocation,
once you explain it to them. There are tougher concepts novices must
understand.

What do you gain, though? Why build further hurdles in a already-tough
context?

 

[kartik]

Read the Java Language Specification, the chapters dealing with fields and
methods... you can do a lot to fields you can't do to methods, and vice
versa. The two concepts just don't work interchangably.

I already read the spec. I don't want to use fields and methods
interchangably, except in the situation I proposed - and what doesn't
work in that case?

For example:
[code deleted]
What should the main print out? My guess would be 5 [...]

I'm not proposing to change the behavior of working code (except code
that relies on a NoSuchFieldException), so whatever the code does now,
it'll continue to do.

That's not a problem; I wasn't proposing changing the semantics of the
invokevirtual instruction for somebody to complain that the parallel
using reflection behaves differently from a hardcoded invocation. What
we do need to change is reflexive field access: it should invoke the
getters & setters when the field isn't found. But that's pretty
logical.

[...] I fail to see the logic in your proposal.

Meaning, you'd consider it logical if a reflexive operation behaves
differently from the hardcoded equivalent?

A field access
is something fundamentally different from a method invocation. With one
you can be sure that the instruction will directly change the object
state with no further side effects. With the other, you invoce a function
that not only can take arbitrarily long, but alos have all kinds of further
effect (even ignoring your original argument).

That's precisely the point. Clients should not be allowed to "directly
change the object state". That violates encapsulation. The only thing
they should be allowed to do is to invoke a method. My proposal
transforms an attempt to do the former into the latter, so you have
the benefits of encapsulation without making an effort to do so, while
preserving compatabaility with existing code, even binary
compatability.

What's more, you need to constantly worry how actual access happens. After
a time, you tend to just call the accessor, which does all kinds of sanity
checks etc. What if your "property" is in fact backted by an accessible
field,
and you depend on the sanity checks / synchronization / other effects of
the
accessor? Errors waiting to happen.


What do you gain, though?

I've already explained it several times. Once again:
1)Simpler syntax (you may not agree with this).
2)You don't have to define accessors till you need them.
3)You don't have to teach novices to make fields private.

 

[Stefan Schulz]

I'm not proposing to change the behavior of working code (except code
that relies on a NoSuchFieldException), so whatever the code does now,
it'll continue to do.

You did not get it. However you define the behaviour of that bit of code,
it runs contrary to intuition.

That's not a problem; I wasn't proposing changing the semantics of the
invokevirtual instruction for somebody to complain that the parallel
using reflection behaves differently from a hardcoded invocation. What
we do need to change is reflexive field access: it should invoke the
getters & setters when the field isn't found. But that's pretty
logical.

[...] I fail to see the logic in your proposal.

Meaning, you'd consider it logical if a reflexive operation behaves
differently from the hardcoded equivalent?

No, that is exactly the point. If i change a public field to a private one
using your method, there still is a declared field that can be retrieved
via Class.getDeclaredFields, but is no longer accessible by reflexive
access. (unless you wish to mix that up as well, and allow access to
private fields if there is a public accessor)

That's precisely the point. Clients should not be allowed to "directly
change the object state". That violates encapsulation. The only thing

Not necessarily. I can imagine Objects that have public fields that should
be accessible. I agree that these are far and few between, but not ever
public field violates encapsulation.

Encapsulation means that _internal_ state must be hidden.

they should be allowed to do is to invoke a method. My proposal
transforms an attempt to do the former into the latter, so you have
the benefits of encapsulation without making an effort to do so, while
preserving compatabaility with existing code, even binary
compatability.

Such a change is incompatible. What if the calling method depends on the
field access semantics? (constant time, guaranteed change)? Not to mention
that reflexive access to a formely public field will now be denied.

I've yet to see a point in it. You keep to iterate the same non-arguments
over
and over again. I'm still waiting for some killer that shows a definite
gain
for all the trouble your proposal introduces.

1)Simpler syntax (you may not agree with this).

It introduces a horrible, impossible-to-untangle confusion what a
dot-operator
does in the case of a field.

2)You don't have to define accessors till you need them.

You always need accessors if you at all rely on the content of the field
for the
internal operation of your class.

3)You don't have to teach novices to make fields private.

You still have to, unless you disallow the public, protected and unmodified
variant of fields (which would kill pretty much all programs)

And that is all i'm going to say about the subject. It may look like a
great idea
to you, but if you really want to have it, use some language that supports
it,
and don't break java over the percieved gain. Java's concepts just do not
mix
too well with it.