Automatically Implemented Properties--why bother?

[raylopez99]

I'm going through a book by Jon Skeet that mentions automatically
implemented properties, but it doesn't do a good job of explaining why
you should bother and what is going on behind the scenes.

For example:

string name;
public string Name
{
get {return name;}
set {name=value;}
}

is the traditional way.

the "new" way (C#3):

public string Name {get; set;}

but what is not clear--is there a variable that's private named 'name'
in the 'new' way? Hidden behind the scenes?

Second, why bother? how does this encapsulate anything? It seems you
can just make Name public and be done with it.

Any help appreciated

RL

[Peter Morris]

public class Impl
{
public string Eggs { get; set; }
}

Is the same as

public class Impl
{
// Fields
[CompilerGenerat ed]
private string <Eggs>k__Backin gField;

// Properties
public string Eggs
{
[CompilerGenerat ed]
get
{
return this.<Eggs>k__B ackingField;
}
[CompilerGenerat ed]
set
{
this.<Eggs>k__B ackingField = value;
}
}
}

As for the point. If you make Name public it is a field not a property, and
as far as I know you can only bind to properties. In addition you can do
this

public string Eggs { get; private set; }

Which you can't with a Field.

--
Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com

[Anthony Jones]

"raylopez99 " <ra********@yah oo.comwrote in message
news:86******** *************** ***********@m74 g2000hsh.google groups.com...

I'm going through a book by Jon Skeet that mentions automatically
implemented properties, but it doesn't do a good job of explaining why
you should bother and what is going on behind the scenes.

For example:

string name;
public string Name
{
get {return name;}
set {name=value;}
}

is the traditional way.

the "new" way (C#3):

public string Name {get; set;}

but what is not clear--is there a variable that's private named 'name'
in the 'new' way? Hidden behind the scenes?

Yes a private field is created to hold the value but its not available
lexically in code so you can only access it via the Name property. This is
a good thing. Apart from reducing the number of lines needed it eliminates
the tendancy to access the value via the private field from code inside the
class. If at some point in the future it was determined the value needn't
be held but can be calculated one needs only to modify the property code,
there would be no need to find all potential uses of the private field.

Second, why bother? how does this encapsulate anything? It seems you
can just make Name public and be done with it.

If you are refering to making a Name field public that would be worse. If
again at a later time you decided you needed to change the Name to a
property for internal reasons you are forced into changing the classes
public interface. With the Name being implemented as a Property to start
with, if such a change is needed it is not apparent to external consumers of
your class.

--
Anthony Jones - MVP ASP/ASP.NET

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yah oo.comwrote:

I'm going through a book by Jon Skeet that mentions automatically
implemented properties, but it doesn't do a good job of explaining why
you should bother and what is going on behind the scenes.

For example:

string name;
public string Name
{
get {return name;}
set {name=value;}
}

is the traditional way.

the "new" way (C#3):

public string Name {get; set;}

but what is not clear--is there a variable that's private named 'name'
in the 'new' way? Hidden behind the scenes?

Yes - as stated in the middle paragraph of P209:

"The compiler generates a private variable that can't be referenced
directly in the source, and fills in the property getter and setter
with the simple code to read and write that variable."

Second, why bother? how does this encapsulate anything? It seems you
can just make Name public and be done with it.

See http://csharpindepth.com/Articles/Ch...iesMatter.aspx

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[qglyirnyfgfo]

Jon

Off topic but didn’t you used to have a video somewhere where you
explained automatic properties?

I just remember you typing at 500 miles per hour in that video.

On Oct 28, 2:49*pm, Jon Skeet [C# MVP] <[e-mail] mwrote:

raylopez99 <raylope...@yah oo.comwrote:

I'm going through a book by Jon Skeet that mentions automatically
implemented properties, but it doesn't do a good job of explaining why
you should bother and what is going on behind the scenes.

For example:

string name;
public string Name
{
get {return name;}
set {name=value;}
}

is the traditional way.

the "new" way (C#3):

public string Name {get; set;}

but what is not clear--is there a variable that's private named 'name'
in the 'new' way? *Hidden behind the scenes?

Yes - as stated in the middle paragraph of P209:

"The compiler generates a private variable that can't be referenced
directly in the source, and fills in the property getter and setter
with the simple code to read and write that variable."

Second, why bother? *how does this encapsulate anything? *It seems you
can just make Name public and be done with it.

Seehttp://csharpindepth.c om/Articles/Chapter8/PropertiesMatte r.aspx

--
Jon Skeet - <[e-mail] m>
Web site:http://www.pobox.com/~skeet*
Blog:http://www.msmvps.com/jon.skeet
C# in Depth:http://csharpindepth.com- Hide quoted text -

- Show quoted text -

[Jon Skeet [C# MVP]]

<qg**********@m ailinator.comwr ote:

Off topic but didn=3Ft you used to have a video somewhere where you
explained automatic properties?

I just remember you typing at 500 miles per hour in that video.

Well remembered: http://csharpindepth.com/Screencasts.aspx

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[raylopez99]

On Oct 28, 6:59*am, "Peter Morris" <mrpmorri...@SP AMgmail.comwrot e:

public class Impl
{
* * public string Eggs { get; set; }

}

Is the same as

public class Impl
{
* * // Fields
* * [CompilerGenerat ed]
* * private string <Eggs>k__Backin gField;

* * // Properties
* * public string Eggs
* * {
* * * * [CompilerGenerat ed]
* * * * get
* * * * {
* * * * * * return this.<Eggs>k__B ackingField;
* * * * }
* * * * [CompilerGenerat ed]
* * * * set
* * * * {
* * * * * * this.<Eggs>k__B ackingField = value;
* * * * }
* * }

}

As for the point. *If you make Name public it is a field not a property, and
as far as I know you can only bind to properties. *In addition you can do
this

public string Eggs { get; private set; }

Which you can't with a Field.

--
Pete
====http://mrpmorris.blogs pot.comhttp://www.capableobje cts.com

Well I don't like this new convention.

Based on the way I code, I would like to know what the
"k__BackingFiel d" compiler generated name is. I don't want it to be
hidden.

Put another way, in this 'traditional' way of coding:

string name;
public string Name
{
get {return name;}
set {name=value;}
}

I would refer to the variable "name" (smaller case, note) throughout
my class, internally. But, with the "new" C#3 convention, I have no
way of knowing what this variable is, since it's hidden now and named
by the compiler.

So I will stick to the older, 'traditional' way of using properties.

RL

[Mythran]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************@m snews.microsoft .com...

<qg**********@m ailinator.comwr ote:

>Off topic but didn=3Ft you used to have a video somewhere where you
explained automatic properties?

I just remember you typing at 500 miles per hour in that video.

Well remembered: http://csharpindepth.com/Screencasts.aspx

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

The page for the URL you posted works, but the link on that page to
"Automatic properties" takes me to a broken page :D

Uh-oh!

Mythran

[Jon Skeet [C# MVP]]

Mythran <My*****@commun ity.nospamwrote :

The page for the URL you posted works, but the link on that page to
"Automatic properties" takes me to a broken page :D

Uh-oh!

Hmm... I'll ask Dmitry...

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yah oo.comwrote:

<snip>

Well I don't like this new convention.

Based on the way I code, I would like to know what the
"k__BackingFiel d" compiler generated name is. I don't want it to be
hidden.

Why not? The whole point of automatic properties are that they're for
trivial ones, where referring to the field and referring to the
property are (at least for the time being) equivalent.

Put another way, in this 'traditional' way of coding:

string name;
public string Name
{
get {return name;}
set {name=value;}
}

I would refer to the variable "name" (smaller case, note) throughout
my class, internally. But, with the "new" C#3 convention, I have no
way of knowing what this variable is, since it's hidden now and named
by the compiler.

So I will stick to the older, 'traditional' way of using properties.

I still don't see why.

Personally I'd like a form of property which prevented the rest of the
class from seeing the variable but still allowed the property code
itself to do stuff. That way I could make sure that my class was using
the property throughout, which means I can't accidentally bypass any
validation, logging etc.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com