How to emluate "properties" in Java?

[Arved Sandstrom]

[...]
That abbreviated syntax, which for you is the least useful aspect of
properties in C#, may well be the most useful aspect of properties for
most C# programmers. I doubt very much that the majority of C# writers
are doing anything but jamming in those { get; set; } pairs for each
field they want to expose.

It has been my experience that that is _not_ how properties are
typically used (as I've already noted).

[ SNIP ]

It's all well and good, Peter, but it doesn't exactly lead me to believe
that there are any deeper meanings to C# properties when someone like
Brad Abrams, an important .NET program manager, describes .NET
properties as syntactic sugar. What he said was, "Properties are like
smart fields, is what I call them. They’re just a way to put some sugar
around fields."

AHS

 

[Arved Sandstrom]

[...] it doesn't exactly lead me to believe
that there are any deeper meanings to C# properties when someone like
Brad Abrams, an important .NET program manager, describes .NET
properties as syntactic sugar. What he said was, "Properties are like
smart fields, is what I call them. They’re just a way to put some
sugar around fields."

If you want to base your entire understanding of the C# language on a
single statement of a single individual at Microsoft, not even one who
happens to be closely involved with the design of the language, I
suppose that's your prerogative.

No doubt, Brad Abrams is a reasonably smart person. But that doesn't
mean he's the last word on language features, and even if he was, that
doesn't mean you can gain a complete understanding of a feature by
reading a single statement he's made.

Pete

Considering the position that Abrams held when he made that statement,
and things like the fact that he's the primary author of the .NET
Framework Design Guidelines, the Common Language Specification, and the
class libraries for the ECMA CLI specification, I would myself take a
statement like that quite seriously.

And yes, it's a single statement. But not one that admits of ay other
interpretation other than that Abrams thinks/thought that .NET
properties are syntactic sugar.

Granted, he is a single guy. And even an original language designer can
be wrong about his or her own language, or misunderstand the path it's
taken, so I do take your point to a certain degree.

It's just that, try as I might, I don't see that there is anything more
to C# properties than syntactic sugar. You mentioned perhaps some
examples where the power of properties stands out - I wouldn't mind a
cite, because nothing I can find on the MS sites is compelling.

AHS

 

[Arved Sandstrom]

[...]
It's just that, try as I might, I don't see that there is anything
more to C# properties than syntactic sugar.

You seem to be using an odd definition of "syntactic sugar". The usual,
commonly accepted definition is of a language feature that accomplishes
nothing more than could be accomplished with the language already using
some other (usually more verbose) syntax.

That commonly accepted definition precludes a feature like properties,
where the compiled output from a program cannot be accomplished in any
other way than the use of that feature in the language.

[ SNIP ]

The term "syntactic sugar" has nothing whatsoever to do with differences
in compiled output. I agree entirely with your definition - it's the one
I'm using. And that definition has nothing to do with object
code/IL/bytecode differences.

The fact is that you can replace every use of a C# property with either
a public member field and/or a public method. That's why properties are
syntactic sugar.

AHS

 

[Arved Sandstrom]

It most certainly does have to do with that. One of the biggest
benefits of having built-in property support is for what's possible
_after_ the code has been compiled. You cannot ignore the compiled
output and still expect to comprehend how properties are useful beyond
simple naming conventions.


If you think that's true, then you aren't using the same definition I'm
using.


No, you can't. If you do that, then you sacrifice a big part of what
makes properties useful.

[ SNIP ]

Educate me then. I'm not being deliberately obstreperous here; I would
genuinely like to find out what this extra is that you say .NET
properties have. I have never run across any MS or non-MS website that
says anything about whatever it is that you are talking about. And
again, I'm not trying to be a simple ass here - I genuinely don't get
what you're trying to say.

Direction to good web articles or even a book or two is fine, and they
can be as advanced as you think is necessary. I have in fact been
following everything you've said in this thread, and the closest I see
to any kind of explanation is a post of yours from about 2115 on the
25th of Feb. There you made two points: one about "more robust data
binding", and one about the help that properties provides to GUI
designers. I'm not particularly concerned about GUI designers, but
perhaps you could direct me to some material that expands on the first
point.

AHS

P.S. We may as well not argue about the definition of syntactic sugar.
What I understand to be the definition of syntactic sugar, as also
defined by Wikipedia, and as I've seen innumerable people use it, never
mentions differences in intermediate or object code.

I might also add, one might want to be careful about striking a note of
infallibility. In the same post of yours I mentioned, you say:

"Note that other naming conventions solve the question of distinguishing
a property from a field. For example, the .NET naming convention
requires properties to start with a capital letter, and field names with
a lower-case. Thus, "a.b = 5" is always setting a field, while "a.B" is
setting a property"."

In fact this is not true. An extremely common .NET convention is
specifically for public member fields and properties both to be
capitalized. More precisely, I've almost always seen properties
capitalized, and I've seen reams and reams of C# that has public member
fields capitalized, including a lot of source by authoritative writers.

 

[news.telesweet.net]

Arved Sandstrom wrote:

You can accomplish the same end-result in Java, but not in a way that
ensures you're really specifically dealing with properties, nor in a
general way that ensures you always have access to (i.e. can identify)
every property present in a class. I.e. it's not precisely the same
functionality, even if what the user sees in the end is the same.

Functionality is defined by what the end-user sees. If what the
end-user sees is the same, then it is the same functionality.

 

[Arved Sandstrom]

[...]
Direction to good web articles or even a book or two is fine, and they
can be as advanced as you think is necessary. I have in fact been
following everything you've said in this thread, and the closest I see
to any kind of explanation is a post of yours from about 2115 on the
25th of Feb. There you made two points: one about "more robust data
binding", and one about the help that properties provides to GUI
designers. I'm not particularly concerned about GUI designers, but
perhaps you could direct me to some material that expands on the first
point.

You can infer conclusions about both points once you actually know what
_really_ happens when you write a property in C# (i.e. as opposed to
forming an opinion about properties in C# without actually know what
they are or how they work). For example, this method becomes possible:
http://msdn.microsoft.com/en-us/library/aky14axb.aspx

[ SNIP ]

Good stuff, thank you. I will digest all this at some leisure.

P.S. We may as well not argue about the definition of syntactic sugar.
What I understand to be the definition of syntactic sugar, as also
defined by Wikipedia, and as I've seen innumerable people use it,
never mentions differences in intermediate or object code.

You are reading that definition much differently than I do. [ SNIP ]

If you would prefer to not argue about the definition of "syntactic
sugar", that's fine with me. But if you choose to hold that position,
you need to actually not argue about the definition of "syntactic sugar".

Yeah, let's leave it at that. We clearly disagree, but it's not relevant
to this discussion.

I have no idea what the above is intended to mean. I've never ever
suggested I'm infallible.


Incorrect. That's not an accepted convention, never mind "an extremely
common" one.

[ SNIP ]

We'll have to disagree. We must be looking at almost completely
non-overlapping code and articles and books over the past X years. And I
don't make a habit of reading SAMS or Que books, or RoseIndia style
websites either. I can see with my own eyes that people are widely
Pascal-casing - not camel casing - instance fields, including public
instance fields (and BTW, MS also recommends strongly not to do public
instance fields but it's very common to do just that).

I didn't say MS .NET convention; I said _an_ extremely common .NET
convention. "An", not "the". Extremely common == accepted. And I'll
stand by that observation.

Not much point in beating this one to death. I use the MS convention
myself, and that's what matters to me.

AHS

 

[Stefan Ram]

What you describe as being a special characteristic of properties (with
regards to plain methods) is just a simple boolean metadata accessible
at runtime through reflection. Java has a generic support for metadata,

When there is no general specification about exactly which
annotation (fully qualified name) does mark a property, this
is less support for tools independent of a special manufacturer,

Simply define this:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
@interface Property { }

Yes, this way everyone has his own, so there will be:

com.manufacturer.a.misc.Property
com.manufacturer.b.general.annotations.Property
com.manufacturer.c.Property
my.own.Property

This is not the same as a single Property annotation for the
whole Java community, similar to - say

java.lang.Override

. (In the same way Java also lacks some common general
interfaces such as

interface Action { void run(); }
interface Function<Y,X> { Y of( X x ); }
interface Add<X> { add( X ); }
interface Possibility { boolean isValid(); }
and so on

with a certain semantics.)

 

[Pitch]

It's just that, try as I might, I don't see that there is anything more
to C# properties than syntactic sugar.

There is a convention. You use properites for values that define an
object's state, values that probably should be serialized. If you have
anything else that needs to be computed depending on the object's state
you use methods. Setters/getters are not so readable.

I believe properties in .NET came from Delphi where their role was also
to expose these values in the IDE's Object Inspector.

Oter than that there is no extra functionality but since it makes code
more readable, I miss properties in Java.

 

[Mike Schilling]

[...]
Direction to good web articles or even a book or two is fine, and
they can be as advanced as you think is necessary. I have in fact
been following everything you've said in this thread, and the
closest I see to any kind of explanation is a post of yours from
about 2115 on the 25th of Feb. There you made two points: one about
"more robust data binding", and one about the help that properties
provides to GUI designers. I'm not particularly concerned about GUI
designers, but perhaps you could direct me to some material that
expands on the first point.

You can infer conclusions about both points once you actually know
what _really_ happens when you write a property in C# (i.e. as
opposed to forming an opinion about properties in C# without actually
know what they are or how they work). For example, this method
becomes possible:
http://msdn.microsoft.com/en-us/library/aky14axb.aspx
That's the GetProperties() method from the System.Type class
(equivalent to Java's java.lang.Class class). There's simply no way
to write that method in Java simply by implementing properties as
conventionally named methods. I assume that you, or any other
reader, can correctly infer the value in such a method.

The Java Beans infrastructure does exactly that: it assumes that methods
that follow the conventions of

public T getX();
public void setX(T);

define properties, and uses reflection to find them.

 

[David Lamb]

No, you can't. If you do that, then you sacrifice a big part of what
makes properties useful.

[ SNIP ]

Educate me then.

I don't know if this applies to any of the specific implementations
previously mentioned, but one characteristics of "properties" as I
understand them is that they have the mathematical property that, in the
absence of parallelism (or with certain restrictions on how parallel
threads/processes can access them, a "property" means that after
a.b = e; ... (code not assigning to a.b) ... x = a.b;
you can deduce x=(the value of e at the indicated point in the program).
This can in principle make possible certain optimizations (and the
proofs they depend on). Using arbitrary methods instead of "properties"
at least makes it harder to analyze. Now that run-time analysis is
common that may no longer be relevant.

 

[Mike Schilling]

[...]
Direction to good web articles or even a book or two is fine, and
they can be as advanced as you think is necessary. I have in fact
been following everything you've said in this thread, and the
closest I see to any kind of explanation is a post of yours from
about 2115 on the 25th of Feb. There you made two points: one about
"more robust data binding", and one about the help that properties
provides to GUI designers. I'm not particularly concerned about GUI
designers, but perhaps you could direct me to some material that
expands on the first point.

You can infer conclusions about both points once you actually know
what really happens when you write a property in C# (i.e. as
opposed to forming an opinion about properties in C# without actually
know what they are or how they work). For example, this method
becomes possible:
http://msdn.microsoft.com/en-us/library/aky14axb.aspx
That's the GetProperties() method from the System.Type class
(equivalent to Java's java.lang.Class class). There's simply no way
to write that method in Java simply by implementing properties as
conventionally named methods. I assume that you, or any other
reader, can correctly infer the value in such a method.

The Java Beans infrastructure does exactly that: it assumes that methods
that follow the conventions of

public T getX();
public void setX(T);

define properties, and uses reflection to find them.

 

[news.telesweet.net]

Exactly. It _assumes_. If the conventions are not followed strictly, it
may return "properties" that are in fact simply poorly named methods
(where "poorly" is defined strictly based on the given naming
convention…the names may or may not really be "poor"), and it won't
return certain properties (including those that follow different
Sun-approved naming conventions) because they don't happen to follow
exactly _that_ naming convention.

Thank you for making my point.

And In C# you are assuming that what one programmer uses the property
idiom for is exactly the same as what you are assuming they are using
it for. If they don't follow the MS convention that you seem to be
prescribing to, then you can have exactly the same problem in C#.

 

[news.telesweet.net]

Not true at all. There is only one "property idiom" in C#, and it's
defined by the language. It's not possible to write a property in C# and
fail to comply with the "convention". It's built into the language.

Of course it is possible. For example, after the following code, what
does x equal?

a.B = 5;
x = a.B;

With C# properties you have absolutely no idea. If you happen to know
that the person who programmed it followed the conventions for
properties, then you could probably say it was 5. If they didn't, you
have no idea, because C# properties are just shorthand for method calls.
Personally I find this extremely distasteful. It's as bad as operator
overloading in my opinion.

 

[news.telesweet.net]

The answer to the question you asked is irrelevant. The question isn't
what a property _does_ but what it _is_.

You are completely failing to see my point. My point is that effective
use of C# properties relies on certain conventions being followed as
much as use of Javabeans properties relies on certain conventions being
followed. Without those conventions, a C# property can do whatever the
hell it wants, and has the potential for creating far more obfuscated
code than the corresponding Java code.

At least if the above example were in Java I could reasonably assume
that all that was going on was that two variables were being assigned
to. In C#, all sorts of crap could be happening, that I, coming to
that code fresh would know nothing about. Personally, I don't like
that. I want to be able to see, at a glance, and without knowing
anything about the objects being used, when control is being passed to
another section of code.

 

[Arved Sandstrom]

I would say the exact same thing about you.


That has nothing to do with the question that has been discussed here.


No. The code would be exactly as obfuscated a the corresponding Java
code, except for the additional problem that Java has which is that you
can't reliably know for sure what in a class is actually supposed to be
a property and what's not.

[ SNIP ]

Just an aside observation about Java, and "properties": a lot of the
time, depending on what kind of Java programming you do, this question
simply never arises. For example, in my line of work the two main times
that I have to follow the getX/setX conventions have to do with JSF EL
and entity class accessors, but there is no thought here that these
methods are "properties" - they are simply accessors. So in the sense
that we have been talking about .NET properties, and why and how they
are useful, I for one don't encounter these use cases when using Java at
all.

This is anecdotal. YMMV. I'm only pointing it out to indicate that for
_me_ Java does *not* have the problem you mention, because in my use of
Java I do not require the "property" concept. It wouldn't actually even
add any value.

AHS