Automatically generating get and set properites for private class data

[Charles]

How often have you seen this kind a of construct in a .NET class:

class A
{
private string b;
public string B
{
get { return b; }
set { b = value; }
}
}

Wouldn't it be nice to have an attribute you could place on the member
data that would automatically generate the corresponding properties?
It would look something like this:

class A
{
[Property(name="B", get=true, set=true)]
private string b;
}

Has anyone see something similar to this? There seems to be no way to
write a custom attribute that generates code at compile time, but
perhaps there's another way to accomplish such a thing?

Charles

 

[Jon Skeet [C# MVP]]

Wouldn't it be nice to have an attribute you could place on the member
data that would automatically generate the corresponding properties?

Not as an attribute, IMO - I'd rather have it as a new keyword (or a
context-sensitive keyword to avoid conflicts).

I'm not terribly keen on attributes affecting compile-time behaviour,
beyond conditional ones...

Jon

 

[Nicholas Paldino [.NET/C# MVP]]

This is going to be in C# 3.0. The syntax will be:

public string MyProperty
{
get;
set;
}

This will auto-magically create the backing field for you. You won't be
able to acess this field, since you won't know what the name of it will be.
Because of this, you should NOT use this language feature if you are going
to adorn the class with a Serializable attribute (the DataContract attribute
is ok, but if you need to have that field stored when the structure is read,
then you will have to go back to the old way).

 

[Mark Itzcovitz]

Automatic properties in C# Version 3:

public string B
{
get;
set;
}

 

[Charles]

Sweet! Thanks for the heads-up.

Charles

 

[Jon Skeet [C# MVP]]

This is going to be in C# 3.0. The syntax will be:

public string MyProperty
{
get;
set;
}

This will auto-magically create the backing field for you. You won't be
able to acess this field, since you won't know what the name of it will be.
Because of this, you should NOT use this language feature if you are going
to adorn the class with a Serializable attribute (the DataContract attribute
is ok, but if you need to have that field stored when the structure is read,
then you will have to go back to the old way).

Hooray - I've been after the field-hiding aspect for ages

I don't remember seeing that on my last skim through the C# 3 spec - I
dare say it's out of date

 

[Bill Butler]

This is going to be in C# 3.0. The syntax will be:

public string MyProperty
{
get;
set;
}

Yesssssssss!!!