Is C# 2.0 syntax of Properties closed?

[=?ISO-8859-2?Q?Marcin_Grz=EAbski?=]

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

 

[Morten Wennevik]

Hi Marcin,

This is just an example that you can have different access modifiers for
get and set. Get is public, set is private, and so on.

Happy coding!
Morten Wennevik [C# MVP]

 

[Guest]

Hi Marcin,

This is just an example that you can have different access modifiers for
get and set. Get is public, set is private, and so on.

Happy coding!

Thanx... but i don't like this syntax. Because it is
self-conflicting.
First i have set property access to public "public" and then i have to
set e.g. set access to "protected" or "private"...

I think that so much better from logical point-of-view looks:

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

// or even

public int MyInt {
get {...}
}

protected int MyInt {
set { ... }
}

Marcin

 

[Daniel O'Connell [C# MVP]]

Thanx... but i don't like this syntax. Because it is
self-conflicting.
First i have set property access to public "public" and then i have to
set e.g. set access to "protected" or "private"...

I think that so much better from logical point-of-view looks:

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

// or even

public int MyInt {
get {...}
}

protected int MyInt {
set { ... }
}

Frankly, while I don't particularly care for the existing syntax, I don't
think either of these are any better. Seperating the accessors makes it less
immedaitly clear that they are related and putting the access modifiers on
the accessor makes it less immediatly clear that the property is public(as
far as most langauges are concerned at any rate, in metadata a property has
no accessibility).

 

[=?ISO-8859-2?Q?Marcin_Grz=EAbski?=]

Hi Daniel,

Frankly, while I don't particularly care for the existing syntax, I don't
think either of these are any better. Seperating the accessors makes it less
immedaitly clear that they are related and putting the access modifiers on
the accessor makes it less immediatly clear that the property is public(as
far as most langauges are concerned at any rate, in metadata a property has
no accessibility).

What do You think about a sample code below...
(I don't know real C# 2.0 syntax rules and this sample is only
for speculate)

internal int MyInt {
get {
// ...
}
protected set {
// is this "protected internal" or "protected" ?
}
}

or

internal int MyInt {
public get {
// is this "internal" or "public" ?
}
set {
// ...
}
}

and what about setting "main" accessor to "protected" or
"private"?

I think that a properties are so close to a methods that it
was no reason to treat them other than a methods.

Marcin

 

[Daniel O'Connell [C# MVP]]

Hi Daniel,


What do You think about a sample code below...
(I don't know real C# 2.0 syntax rules and this sample is only
for speculate)

internal int MyInt {
get {
// ...
}
protected set {
// is this "protected internal" or "protected" ?
}
}

or

internal int MyInt {
public get {
// is this "internal" or "public" ?
}
set {
// ...
}
}

and what about setting "main" accessor to "protected" or
"private"?

This is where things get tricky. If I was writing the complier I would issue
an error in both cases because you are providing an accessor at greater
accessibility than the property. IMHO, explicit accessor access modifiers
should only be able to reduce accessibility.

I think that a properties are so close to a methods that it
was no reason to treat them other than a methods.

In that case, then, I would say that properties should be done away with and
java like GetXXX and SetXXX should be used instead. A property *is not* a
method as far as the langauge is concerned. Its a field with accessors that
happen to be implemented as methods in the runtime.

 

[Jon Skeet [C# MVP]]

In that case, then, I would say that properties should be done away with and
java like GetXXX and SetXXX should be used instead. A property *is not* a
method as far as the langauge is concerned. Its a field with accessors that
happen to be implemented as methods in the runtime.

Here I disagree. It's far closer to a method call than a field, to my
mind. It has the syntax of a field, but the semantics of a method call,
which is why you can't use a property as a ref parameter, for instance.

 

[Frans Bouma [C# MVP]]

What do You think about a sample code below...
(I don't know real C# 2.0 syntax rules and this sample is only
for speculate)

internal int MyInt {
get {
// ...
}
protected set {
// is this "protected internal" or "protected" ?
}
}

This would beg for a separation of get and set clauses in a
construction I think. I then would opt for:
internal int MyInt get
{
// code
}

internal protected int MyInt set
{
}

or

internal int MyInt {
public get {
// is this "internal" or "public" ?
}
set {
// ...
}
}

and what about setting "main" accessor to "protected" or
"private"?

The two are combined: the property name and the get or set, you
can't see them separated. So specifying 2 accessor operators on different
places is not that correct.

I think that a properties are so close to a methods that it
was no reason to treat them other than a methods.

They're not close to methods, if they were they'd accept
parameters. (Ok, the indexer property accepts a parameter). So they can't
be threated as methods, more like fields, or better: virtual fields.

FB

 

[Jon Skeet [C# MVP]]

They're not close to methods, if they were they'd accept
parameters. (Ok, the indexer property accepts a parameter). So they can't
be threated as methods, more like fields, or better: virtual fields.

I think they're much more like methods than parameters. Consider:

o They end up as methods internally
o They can be virtual, overridden etc
o They *can* take parameters, as indexers - although C# is quite
restrictive in terms of its indexers, compared with other .NET
languages.
o They can't be used as ref/out parameters

So, in what way are they like fields *apart* from in access syntax?

 

[Bjorn Abelli]

...

I think they're much more like methods than parameters. Consider:
[snip]

o They *can* take parameters, as indexers - although C#
is quite restrictive in terms of its indexers, compared
with other .NET languages.

You can even extend that argument, as *all* properties with a setter can
make use of the default argument: value.

So it definitely is closer to methods than fields.

Furthermore, even Microsoft obviously consider properties in terms of
methods. If you reverse engineer a class into UML with the combination
VS.NET/Visio, properties show up in the operation section of the class!



// Bjorn A

 

[Frans Bouma [C# MVP]]

I think they're much more like methods than parameters. Consider:

o They end up as methods internally

but that's not important to the developer.

o They can be virtual, overridden etc
o They *can* take parameters, as indexers - although C# is quite
restrictive in terms of its indexers, compared with other .NET
languages.
o They can't be used as ref/out parameters

So, in what way are they like fields *apart* from in access syntax?

In their semantic behaviour, more or less:

int val = Foo.Bar; // A
int val = Foo.Bar; // B
int val = Foo.Bar(); // C

is A a property or public field? Or is B? C is a method, no
question about it. As MS says: if it takes a lot of time, make it a method
instead of a property. Properties are mostly used in scenario's where you
want a value, which is retrieved with very little logic, or to set a value
in a class.

They can't be used like you'd use fields, agreed, that's why they
shouldn't be seen as fields, but properties. After all, properties can
contain additional logic like conversion code, checks and what have you.
Fields don't. However for the user of the property, that's not important.

One clear separation of properties from methods has been left
undiscussed: properties can appear at the left-hand side of an expression,
methods can't.

FB

 

[Frans Bouma [C# MVP]]

You can even extend that argument, as *all* properties with a setter can
make use of the default argument: value.

the property's value, I don't see that as a default argument of a
method, as methods can't have default arguments.

So it definitely is closer to methods than fields.

methods can't be used at the left-hand side of an expression:

Foo.Bar() = 10; // *rrrt*
Foo.Bar = 10; // *ping!*

.. so using that they have to be closer to fields than methods!

I think "closer to ABC" is a bit academic. They're nor fields nor
methods, they're properties.

Furthermore, even Microsoft obviously consider properties in terms of
methods. If you reverse engineer a class into UML with the combination
VS.NET/Visio, properties show up in the operation section of the class!

Yes, this is interesting Below the surface they have to be
transformed into methods apparently. Which is not that strange, as it
would be impossible to use a C# class with properties in a J# application,
or in a piece of MC++ code

FB

 

[Jon Skeet [C# MVP]]

but that's not important to the developer.

I think it's something all developers should be aware of, myself.

In their semantic behaviour, more or less:

int val = Foo.Bar; // A
int val = Foo.Bar; // B
int val = Foo.Bar(); // C

Less like fields than methods, in my opinion.

is A a property or public field? Or is B? C is a method, no
question about it. As MS says: if it takes a lot of time, make it a method
instead of a property. Properties are mostly used in scenario's where you
want a value, which is retrieved with very little logic, or to set a value
in a class.

Mostly, yes. But you need to be aware that they *are* method calls.

They can't be used like you'd use fields, agreed, that's why they
shouldn't be seen as fields, but properties. After all, properties can
contain additional logic like conversion code, checks and what have you.
Fields don't. However for the user of the property, that's not important.

One clear separation of properties from methods has been left
undiscussed: properties can appear at the left-hand side of an expression,
methods can't.

True, but again, that's just a difference in syntax:

Property = value;

is just translated to:

SetValue (value);

There's a clear translation from any use of properties to the
equivalent use of methods. Anything you can do with a property could be
done with a method. The same is *not* true of fields.

 

[Frans Bouma [C# MVP]]

I think it's something all developers should be aware of, myself.

Could you elaborate on this, please? I don't see why developers
should be aware of this that much.

Less like fields than methods, in my opinion.

erm, there is no difference between A and B, and still you say B
(or A ) is more like C than B is to A?

Mostly, yes. But you need to be aware that they *are* method calls.

because they can take a given amount of time due to the logic
inside the methods? If that's your argument, then I agree.

True, but again, that's just a difference in syntax:

Property = value;

is just translated to:

SetValue (value);

There's a clear translation from any use of properties to the
equivalent use of methods. Anything you can do with a property could be
done with a method. The same is *not* true of fields.

Ok, semantically, there is indeed not a need for properties, as you
can formulate the get and set as 2 methods, agreed. Just to nittpick: if I
create 2 delegates for the get and set methods, can't I mimic everything I
can do with a field? (ok not left-hand-sides of expressions)

FB

 

[Jon Skeet [C# MVP]]

Could you elaborate on this, please? I don't see why developers
should be aware of this that much.

Well, they need to be aware that they can make properties do more than
return/set fields (which has come up as a question before now, so it's
not as obvious as one might thing), and that also others may make
properties do more than that too.

erm, there is no difference between A and B, and still you say B
(or A ) is more like C than B is to A?

They're more like fields in syntax, as I've said before. I regard
sematnics as more important than syntax, however.

because they can take a given amount of time due to the logic
inside the methods? If that's your argument, then I agree.

Not just in terms of time, but in terms of what they can do.

Ok, semantically, there is indeed not a need for properties, as you
can formulate the get and set as 2 methods, agreed. Just to nittpick: if I
create 2 delegates for the get and set methods, can't I mimic everything I
can do with a field? (ok not left-hand-sides of expressions)

No. You can't use them as output or reference parameters. They won't
have any effect on garbage collection, even if their types are
reference types. They don't (in themselves) have any effect on the size
of an object. The latter two aren't so much things that you can do with
a field so much as effects the fields have, admittedly.

Properties are just syntactic sugar for methods, basically, with a bit
of extra support in the reflection libraries. They make methods *look*
like fields, syntactically - but they still *behave* like methods.

 

[Daniel O'Connell [C# MVP]]

Here I disagree. It's far closer to a method call than a field, to my
mind. It has the syntax of a field, but the semantics of a method call,
which is why you can't use a property as a ref parameter, for instance.

I mean much more as a concept. It is a method call as far as implementation
goes, plain and simple, which is why you can't use a ref parameter(at that,
the C# team could probably have created syntax that would allow a property
with both a get and a set to be passed as a ref or an out parameter, it
would just be more confusing). I consider that more of a restriction of
implementation than of concept. My point is while it is a method, you
shouldn't treat it like a method(as far as usage and syntax goes) or you
will end up defeating the point of properties to begin with. As I said, its
what it is to the langauge(which I consider to be a singular field-like
entity with watchdog\accessor code associated) moreso than to the CLR(which
is a set of methods comprising access to the underlying data). While it must
be treated as a method(or atleast considered as such) much of the time in
reality, I think the language should stick to a more conceptual view.

 

[Jon Skeet [C# MVP]]

I mean much more as a concept. It is a method call as far as implementation
goes, plain and simple, which is why you can't use a ref parameter(at that,
the C# team could probably have created syntax that would allow a property
with both a get and a set to be passed as a ref or an out parameter, it
would just be more confusing). I consider that more of a restriction of
implementation than of concept. My point is while it is a method, you
shouldn't treat it like a method(as far as usage and syntax goes) or you
will end up defeating the point of properties to begin with. As I said, its
what it is to the langauge(which I consider to be a singular field-like
entity with watchdog\accessor code associated) moreso than to the CLR(which
is a set of methods comprising access to the underlying data). While it must
be treated as a method(or atleast considered as such) much of the time in
reality, I think the language should stick to a more conceptual view.

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.

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.

 

[Daniel O'Connell [C# MVP]]

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(Associated get and set, field
like syntax, etc) suggests that they shouldn't be considered as just
syntactic sugar for methods(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). As Frans said in another post in this
thread(paraphrased), a field is a field, a method a method, and a property a
property. 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.

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.

I agree. Knowing what the underlying implementation does is vital for anyone
writing a major piece of code. I would argue, at times, that its less
important to know how things work underneath if you are just writing a
script or other minor thing. I just don't always agree with the distinction
of syntactic sugar vs primary langauge feature. Much of a HLL is syntactic
sugar. You don't really need a good number of constructs to write proper
programs(for loops, switches, using(in all of its forms), lock, default
event accessors, else), but they certainly make life easier. Taking it far
enough you don't even need arithmetic operators to perform work properly, if
you are willing to dive to an assembly language, it still makes life
considerably easier to use them.

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

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

 

[Jon Skeet [C# MVP]]

Whereas I consider the field like qualities(Associated 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.

(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(paraphrased), 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.

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.

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.

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

 

[Frans Bouma [C# MVP]]

Well, they need to be aware that they can make properties do more than
return/set fields (which has come up as a question before now, so it's
not as obvious as one might thing), and that also others may make
properties do more than that too.

ok, as long as the developer also realises that a property
shouldn't do too much (or take too much time). (unless databinding
scenario's force you to)

No. You can't use them as output or reference parameters. They won't
have any effect on garbage collection, even if their types are
reference types. They don't (in themselves) have any effect on the size
of an object. The latter two aren't so much things that you can do with
a field so much as effects the fields have, admittedly.

Can't I pass a delegate pointing to a SetValue() method which in
fact does the same as setting a field's value? (Academic example). But
indeed, you can't mimic everything.

Properties are just syntactic sugar for methods, basically, with a bit
of extra support in the reflection libraries. They make methods *look*
like fields, syntactically - but they still *behave* like methods.

I wouldn't go that far to call them syntactical sugar, as they're
somewhat essential for databinding for example, as you can't bind to a
pair of methods. (or you have to create a property descriptor object which
calls these methods, but that almost looks like a delegate setting a field
just for the sake of the fact that you can ). Where do you draw the
line? I find everything that is generated by the compiler not part of the
language, otherwise you can call a lot of stuff syntactic sugar
(foreach for example)

It's indeed a vague area, the behaviour is indeed in general more
like methods, the usage is more like fields. I think as long as developers
realize that properties can do more than fields and that, normally, a
property will do very little behind the scenes (otherwise it would have
been a method) and should do little behind the scenes, the question what
they really are is not that important, as IMHO for both situations (they
are more like fields (usage), noooo they are more like methods
(construction, compiler output)) have good arguments (imho)

FB