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

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

Is the same as

public class Impl
{
// Fields
[CompilerGenerated]
private string <Eggs>k__BackingField;

// Properties
public string Eggs
{
[CompilerGenerated]
get
{
return this.<Eggs>k__BackingField;
}
[CompilerGenerated]
set
{
this.<Eggs>k__BackingField = 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

"raylopez99" <(E-Mail Removed)> wrote in message
news:86ac7e9a-def6-47d8-b6e5-(E-Mail Removed)...
> 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

raylopez99 <(E-Mail Removed)> wrote:
> 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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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] <sk...@pobox.com> wrote:
> raylopez99 <raylope...@yahoo.com> wrote:
> > 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.com/Articles/Chapter8/PropertiesMatter.aspx
>
> --
> Jon Skeet - <sk...@pobox.com>
> 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 -

<(E-Mail Removed)> wrote:
> 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 - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

On Tue, 28 Oct 2008 06:50:41 -0700 (PDT)
raylopez99 <(E-Mail Removed)> wrote:
>
> 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?
>

Such questions are often best dealt with by looking to the
authoritative source: the compiler itself. .NET makes this pretty easy.

Take the example C# source code:

======================================
using System;

public class ExampleProperties {
public static void Main() {
new ExampleProperties();
}

internal string Name {
get;
set;
}

public ExampleProperties() {
Name = "foo";

Console.WriteLine(Name);
}
}
======================================

Compile this to an assembly using the C# compiler, and take a look at
the disassembly of the IL; you can learn a lot about how the compiler
does things that way.

The output shows that there is a private string "<Name>k__BackingField"
contained within the class. There is also a set_Name(string) method
and a get_Name(string) method which modify the '<Name>k__BackingField".

If you modify it so that you have a private variable mName, and fill-in
the property to get and set it, the effect is the same, but you've
explicitly set the name of the property's internal variable.

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

Properties are part of the public interface for a class. Using a
empty, default property such as above makes the value available to
consumers of the class, while leaving the implementation details free
to you to figure out. Properties are, after all, nothing but veiled
method calls.

Say that you want to make it read-only? Remove the "set;".
Write-only? Do the inverse. Want to add some verification logic to
the setter? Okay, go ahead---create the private variable, fill in the
get using default behavior, and fill in the logic for the set method.
Want to add something extra to the returned value later on? Modify the
"get" routine to do it for you. Want to make it something dynamic
altogether? Use the default for a stub, and fill in the logic later.
There are many, many uses.

--- Mike

--
My sigfile ran away and is on hiatus.
http://www.trausch.us/

On Oct 28, 6:59*am, "Peter Morris" <mrpmorri...@SPAMgmail.com> wrote:
> public class Impl
> {
> * * public string Eggs { get; set; }
>
> }
>
> Is the same as
>
> public class Impl
> {
> * * // Fields
> * * [CompilerGenerated]
> * * private string <Eggs>k__BackingField;
>
> * * // Properties
> * * public string Eggs
> * * {
> * * * * [CompilerGenerated]
> * * * * get
> * * * * {
> * * * * * * return this.<Eggs>k__BackingField;
> * * * * }
> * * * * [CompilerGenerated]
> * * * * set
> * * * * {
> * * * * * * this.<Eggs>k__BackingField = 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.comhttp://www.capableobjects.com

Well I don't like this new convention.

Based on the way I code, I would like to know what the
"k__BackingField" 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

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> <(E-Mail Removed)> wrote:
>> 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 - <(E-Mail Removed)>
> 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

Uh-oh!

Mythran

On Wed, 29 Oct 2008 08:39:14 -0700 (PDT)
raylopez99 <(E-Mail Removed)> wrote:

> Well I don't like this new convention.
>
> Based on the way I code, I would like to know what the
> "k__BackingField" compiler generated name is. I don't want it to be
> hidden.

Part of the reason for hiding it is that the Property get/set methods
are the only ones that should be playing with the private variable,
unless there is a *really* good reason to have other things messing
with it. Say that you have a class that represents a text console
window, and you want to set the width, and you have a private variable
(this.mWidth) and a public property (this.Width). Even within your
class, you'll use "this.Width", letting your properties abstract the
variable and handle it in terms of checking that, say, mWidth is never
going to be >= 200. Do you understand what I'm trying to convey?

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

Correct. Again, that's the whole point: you don't need to know the
name of the private variable that backs the public property. It's
really a good idea to use automatic properties, if you don't have any
reason to have a backing variable that you have access to. Think about
that carefully; _why_ does your private variable need to be accessed by
your class? It'd probably be better to use the property as a gateway
to the variable whether you're using the variable internally or
externally.

--- Mike

--
My sigfile ran away and is on hiatus.
http://www.trausch.us/