Simplified property syntax?

[Guest]

Is there or should there be a simplified property syntax?

For example we have to write:
class MyClass {
private int _field;
public int Field { get { return _field;} set { _field=value}}
}

What if instead you could write:

class MyClass {
public property int Field;
}

Is something like this syntax available? If not should it be? It seems this
is much cleaner and prevents forcing writing a backing store for each
property seperately.

The benefit of this is cleaner coding for properties that just use a backing
field, plus compatibility to later change the implementation for that field
if needed without breaking the interface.

 

[=?iso-8859-1?Q?Lasse=20V=e5gs=e6ther=20Karlsen?=]

Is there or should there be a simplified property syntax?

For example we have to write:
class MyClass {
private int _field;
public int Field { get { return _field;} set { _field=value}}
}
What if instead you could write:

class MyClass {
public property int Field;
}
Is something like this syntax available? If not should it be? It
seems this is much cleaner and prevents forcing writing a backing
store for each property seperately.

The benefit of this is cleaner coding for properties that just use a
backing field, plus compatibility to later change the implementation
for that field if needed without breaking the interface.

I'm sure I'm missing something obvious here but wouldn't the only difference
between:

public int Field;

and the hypothetical:

public property int Field;

be that Reflection would tag one as a field and the other as a property?
Would there actually be anything you could change with this and thus "change
the interface"?

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

And what exactly is the difference between your proposed feature and making
your variable public?

 

[Nick Hounsome]

I'm sure I'm missing something obvious here but wouldn't the only
difference between:

public int Field;

and the hypothetical:

public property int Field;

be that Reflection would tag one as a field and the other as a property?
Would there actually be anything you could change with this and thus
"change the interface"?

Properties are implemented as methods (set_Field and get_Field in this
case). The compiler would need to create these and the underlying field.

Personaly I can live with the extra typing.

 

[Guest]

When you have a lot of properties that is a lot of extra code and typing, and
unless using a tool you could even cut and paste in the wrong backing store
for a property. It just seems something like this would be cleaner since it
is a fairly common idiom to have a backing store variable.

 

[Guest]

If you make your variable public you don't have the option later to change
your implementation, since the compiler/CLR would allow direct access to the
field. By saying it is a property it will actual compile to get_ set_
methods so that later if you wanted to make a change where a simple backing
store variable no longer was viable you could without breaking existing code
that used your class.

 

[Guest]

You have this option in C++/CLI.
It's very handy for cases where the get and set are both single lines. You
aren't the only one who finds typing 11 lines for a 'dumb' property annoying
(counting the braces...).
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C# to C++ converter & VB to C++ converter
Instant J#: VB to J# converter

 

[Guest]

Thanks for the reminder on the C++/CLI-- I thought I remembered something
like this but couldn't find it on the C# side... forgot it was C++/CLI.
Certainly C# could use this.

 

[Guest]

It's even more of a relief in C++/CLI since normally you have to repeat the
return type in three places in a C++/CLI long-hand property - property
header, get, and the set (never could figure out the logic behind that).
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C# to C++ converter & VB to C++ converter
Instant J#: VB to J# converter

 

[Nick Hounsome]

When you have a lot of properties that is a lot of extra code and typing,
and
unless using a tool you could even cut and paste in the wrong backing
store
for a property. It just seems something like this would be cleaner since
it
is a fairly common idiom to have a backing store variable.

If you have that many properties it is probably a poor OO design.

In a good OO design you ask objects to do things for you - you don't grab
all their data and do it yourself.

 

[Jon Skeet [C# MVP]]

Is there or should there be a simplified property syntax?

<snip>

Yes, I believe there should be, for the reasons you've given. In
addition, I'd like to be able to declare a field "inside" a property
declaration so that it's only available within that property (but has
the same lifetime as if it were declared outside). That would prevent
the field from accidentally being used within the class where the
property should be used instead. There are a few gotchas with this
approach, mostly involving serialization, but I think it would be
useful.

 

[Guest]

I'd agree with that as well. Is there an official suggestion submission
location we can send them to for MS?

 

[Jon Skeet [C# MVP]]

I'd agree with that as well. Is there an official suggestion submission
location we can send them to for MS?

I submitted that one ages ago, although more voices wouldn't hurt.

You could make a full feature request on the MSDN product feedback
centre:

http://lab.msdn.microsoft.com/productfeedback/default.aspx

 

[Guest]

Thanks I added one.

I submitted that one ages ago, although more voices wouldn't hurt.

You could make a full feature request on the MSDN product feedback
centre:

http://lab.msdn.microsoft.com/productfeedback/default.aspx