Is C# 2.0 syntax of Properties closed?

[Marcin Grzêbski]

I red MSDN article of C# 2.0 this week... and i found
very strange syntax for properties e.g.:

public int MyIntValue {
get {
// ...
}
protected set {
// ...
}
}

.... Is this syntax defined and obligatory?

Maybe it's not only my feeling that aboved syntax is
not a best choice.
Any answer and discussion will be very interesting.

Marcin

[Daniel O'Connell [C# MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Daniel O'Connell [C# MVP] <[e-mail]> wrote:

> I think we'll probably have to disagree on this. I think there are just
> so many differences between properties and fields (space and garbage
> collection implications, exceptions, time taken, limitations such as
> ref/out etc) that thinking of them as fields leads to far more
> confusion than thinking of them as syntactic sugar over method calls.
Whereas I consider the field like qualities(Assoc iated get and set, field
like syntax, etc) suggests that they shouldn't be considered as just
syntactic sugar for methods

But those qualities *are* just the syntactic qualities - they're just
easier syntax for calling the methods. In what way *isn't* that
syntactic sugar, albeit very "good" sugar? As you say later on, there's
extra CLR support for properties, but I would say that at least
*nearly* all the stuff that makes them appear field-like is just
syntactic sugar.

I'll agree, with the caveat that a property is there strictly to provide
field like access, which I consider a bit ironic. A property is a set of
methods that exist so that languages can treat them like fields
syntactically

(as a note, I generally consider it bad form to
use a field as a ref or an out, I'd rather use a variable and assign the
field post-method).

Agreed :)

As Frans said in another post in this
thread(paraphra sed), a field is a field, a method a method, and a
property a
property.

And I'd be happy with that - it's when people claim that a property is
more "field-like" than "pair-of-methods-like" that I have problems,
because it's *only* the syntax which is field-like, not the semantics.

In the language, which is what the original post was about at that, syntax
tends to matter a bit more than semantics. In programming the semantics
matter more.

I think its all a matter of where each of us thinks the concept
lies. I doubt any of our idea of what properties are\should be are really
taht different, they just happen to lie on opposite sides of the "ideal
property" line.

Sure.

<snip agreement stuff>

Beyond that, most people probably still don't understand how properties
really work. They know that they compile to 2 methods(In C# and VB
atleast,
thats not really a restriction) prefixed with get_ and set_(although that
isn't strictly required either), but fewer seem to realize that a
property
itself has no accessibility or even that a property is a seperate
metadata
construct which associates those methods(in other words, the methods
themselves do not make up the property, the property references the
methods).

That's fine - the fact that they're compiled to methods is all that I
would particularly urge people to know. The fact that they have
semantics which are very close to methods is important - the rest is
only important to a few people who are either doing low-level stuff or
are just incorrigibly nosy, like ourselves. :)

Being nosy has its perks, ;)

Personally, given the runtime support for properties, to be fully correct
I
would probably be hesitant to call properties syntactic sugar, although
the
compiler does offer sugary syntax for defining them, the concept is baked
into the runtime as properties. The compiler would have to provide
something
to distinguish them, perhaps like the __property keyword in C++.
Yes, there definitely more to it than *just* syntactic sugar -
apologies for the previous over-generalisation. The bits that make them
look like fields are just syntactic sugar though, IMO :)

Yes, that I'll agree on.
--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Frans Bouma [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.co m> wrote in
news:MP******** *************** *@msnews.micros oft.com:

Daniel O'Connell [C# MVP] <[e-mail]> wrote:

> I think we'll probably have to disagree on this. I think there are
> just so many differences between properties and fields (space and
> garbage collection implications, exceptions, time taken, limitations
> such as ref/out etc) that thinking of them as fields leads to far
> more confusion than thinking of them as syntactic sugar over method
> calls.

Whereas I consider the field like qualities(Assoc iated get and set,
field like syntax, etc) suggests that they shouldn't be considered as
just syntactic sugar for methods

But those qualities *are* just the syntactic qualities - they're just
easier syntax for calling the methods. In what way *isn't* that
syntactic sugar, albeit very "good" sugar? As you say later on, there's
extra CLR support for properties, but I would say that at least
*nearly* all the stuff that makes them appear field-like is just
syntactic sugar.

But these syntactic qualities reach very far. You can bind a
collection with object instances of a class with properties to a grid
without having to implement ITypedList to produce custom property
descriptors which call into the methods.

It's easier, but not just 'easier', it helps tremendously in some
areas as the usage of classes in a data-binding scenario can become very
complex (ITypedList is no picknick)

So this sugar tastes really good :) (and is IMHO far less sugar
than, say, foreach)

As Frans said in another post in this
thread(paraphra sed), a field is a field, a method a method, and a
property a property.

And I'd be happy with that - it's when people claim that a property is
more "field-like" than "pair-of-methods-like" that I have problems,
because it's *only* the syntax which is field-like, not the semantics.

Agreed! :)

FB

--
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog: http://weblogs.asp.net/fbouma
Microsoft C# MVP

[cody]

> I don't regard the phrase "syntactic sugar" as derogatory like some

people do, btw. The using(...) statement is syntactic sugar, but
incredibly useful - just like properties. That said, I think it's
important to recognise syntactic sugar for what it is, and know what
lies behind it.

The whole OOP itself (objects, interfaces,virt ual methods..) is just
syntactic sugar. You could do everything by yourself, building your own
vtables and so on.
All higher level programming languages are only syntactical sugar that makes
inputting machine instructions in the computer easier than per hand.

But syntactical sugar is good when it makes the code more readable and
selfexplanory so idea of properties looking like fields is not that bad.
The only problem is that you never know wheather a call to a certain propery
is a simple field access internally or wheather the property most do
expensive calculation to return you the value you want. But the same problem
you would have with an old school getter method so who cares.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Marcin Grzêbski]

Wow!

I didn't expect that this thread discussion takes so far...
far... from my question.

Really i want to ask You (group) for personal feeling
of new concept of Properties syntax.

My todays "C# code rules" are standing before serious question:
where the new "two accesors" properties would fit?

Marcin

PS: I know that my english is weak... but i can try to
explain any question :)