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

[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]

[Marcin Grzębski]

Morten Wennevik wrote:

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

"Marcin GrzA?bski" <mg*******@taxu ssi.no.com.spam .pl> wrote in message
news:c4******** **@nemesis.news .tpi.pl...

Morten Wennevik wrote:

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

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

Marcin

[Marcin Grzêbski]

Hi Daniel,

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

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

"Marcin Grzebski" <mg*******@void .taxussi.com.pl .void> wrote in message
news:c4******** ***@mamut1.aste r.pl...

Hi Daniel,

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

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

[Jon Skeet [C# MVP]]

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

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.

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

Marcin Grzêbski <mg*******@void .taxussi.com.pl .void> wrote in
news:c4******** ***@mamut1.aste r.pl:

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

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

[Jon Skeet [C# MVP]]

Frans Bouma [C# MVP] <pe************ ******@xs4all.n l> wrote:

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.

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?

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

[Bjorn Abelli]

"Jon Skeet [C# MVP]" wrote...

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