simplifying use of properties

java-programmer, simplifying use of properties "Stefan Schulz" <email***@***.com> wrote in message news:<opsg4x3eg6q1fd9p@localhost>...
> 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 merit? Properties are supported in many languages like Python,
> >> > Ruby, C# and (I think) VB.
> >>
> >> So what? They are in java too (see the public modifier for fields) ;)
> > Once you have a public field in Java, you can't later replace it with
> > accessor methods without breaking clients. But in Python, Ruby & C#,
> > you can. That is what I meant by "properties" as opposed to "fields"
> > or "instance variables".
>
> 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.

>
> >> It will however make it even more of a living hell to explain tonovices
> >> that a setter/getter pair need not be backed by one andonly one field
> >> of the arguemnt type.
> >
> > Getter/setter pairs that are not backed with fields are used all the
> > time in Java. I'm only proposing an easier syntax for their use.
> > Regarding the novices bit, OO theory says that when you call a method,
> > you should *not* be concerned with how it's implemented. I feel you
> > should not be telling novices that a getter/setter pair always has to
> > be backed with a field.
>
> 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.

java-programmer >> simplifying use of properties "Stefan Schulz" <email***@***.com> wrote in message news:<opsg4x3eg6q1fd9p@localhost>...
> 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 merit? Properties are supported in many languages like Python,
> >> > Ruby, C# and (I think) VB.
> >>
> >> So what? They are in java too (see the public modifier for fields) ;)
> > Once you have a public field in Java, you can't later replace it with
> > accessor methods without breaking clients. But in Python, Ruby & C#,
> > you can. That is what I meant by "properties" as opposed to "fields"
> > or "instance variables".
>
> 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.

>
> >> It will however make it even more of a living hell to explain tonovices
> >> that a setter/getter pair need not be backed by one andonly one field
> >> of the arguemnt type.
> >
> > Getter/setter pairs that are not backed with fields are used all the
> > time in Java. I'm only proposing an easier syntax for their use.
> > Regarding the novices bit, OO theory says that when you call a method,
> > you should *not* be concerned with how it's implemented. I feel you
> > should not be telling novices that a getter/setter pair always has to
> > be backed with a field.
>
> 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.

java-programmer >> simplifying use of properties On 9 Nov 2004 01:54:23 -0800, kartik <email***@***.com> wrote:

>> 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?

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.

>>> Getter/setter pairs that are not backed with fields are used all the
>>> time in Java. I'm only proposing an easier syntax for their use.
>>> Regarding the novices bit, OO theory says that when you call a method,
>>> you should *not* be concerned with how it's implemented. I feel you
>>> should not be telling novices that a getter/setter pair always has to
>>> be backed with a field.
>>
>> 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.

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

--

Whom the gods wish to destroy they first call promising.

Posted: 2004-11-10 15:25:00

java-programmer >> simplifying use of properties "Stefan Schulz" <email***@***.com> wrote in message news:<opsg69puauq1fd9p@localhost>...
> On 9 Nov 2004 01:54:23 -0800, kartik <email***@***.com> wrote:
>
> >> 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?
>
> 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.
>
> >>> Getter/setter pairs that are not backed with fields are used all the
> >>> time in Java. I'm only proposing an easier syntax for their use.
> >>> Regarding the novices bit, OO theory says that when you call a method,
> >>> you should *not* be concerned with how it's implemented. I feel you
> >>> should not be telling novices that a getter/setter pair always has to
> >>> be backed with a field.
> >>
> >> 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.
>
> 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.

Posted: 2004-11-10 16:58:00

java-programmer >> simplifying use of properties On 9 Nov 2004 23:24:35 -0800, kartik <email***@***.com> wrote:

> 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.

--

Whom the gods wish to destroy they first call promising.