class properties

[mp]

trying to understand properties
normally i would create a private variable and return that in a get, assign
it in a set
class TestProperty
{
private List<string> _someList= new List<string>();
public List<string> SomeList { get{return _someList;} set{_someList
= value;} }
...}

i see in c# the type of property that doesn't use a variable (must create a
hidden var behind the scenes or something...)
class TestProperty
{
public string strProp { get; set; }
...}

I got to wondering if I was wasting a variable by using the first (more
verbose) style
so i tried it with a list but that didn't work because (naturally) the list
was null

class TestProperty
{
public List<string> SomeList { get; set; }
public TestProperty()
{
}
public void Test()
{
// A first chance exception of type
'System.NullReferenceException'
SomeList.Add ("Test1");
}
}

yet with a string it does work...although a string is also an object so not
sure why i didn't get the same null reference exception

class TestProperty
{
public string strProp { get; set; }

public TestProperty()
{
}
public void Test()
{ //this works
strProp = "Test strprop";
}
}

appreciate any background or sites that explain why the difference...
i searched msdn and most examples have the more verbose style with private
variable returned from a property
there's probably a good explanation in there somewhere but i haven't
stumbled on to it yet.
and maybe the style that doesn't use a variable isn't any more efficient
than the one that does

i imagine if the class doesn't have to interact with the value during its
lifetime other than to receive a setting from client and return it when
asked, then the variable is of not much use...
but if the class in any method needs to manipulate the variable, then the
private var is useful(though it could probably access it's own property i
would guess...so i'm not sure about that either)

thanks for any input
mark

 

[Jeff Johnson]

I got to wondering if I was wasting a variable by using the first (more
verbose) style
so i tried it with a list but that didn't work because (naturally) the
list was null

class TestProperty
{
public List<string> SomeList { get; set; }
public TestProperty()
{
}
public void Test()
{
// A first chance exception of type
'System.NullReferenceException'
*******

SomeList.Add ("Test1");
}
}

Now it'll work. See the difference? If, in your string example, you had
tried to, say, get a substring before you set the value you'd have gotten
the same error.

 

[mp]

Now it'll work. See the difference? If, in your string example, you had
tried to, say, get a substring before you set the value you'd have gotten
the same error.

ah, but you don't have to new a string...but you do some other objects...why
is that?
i guess the system is newing the variable behind the scenes basically?

so do you think the "variable-less" property style is more efficient than
creating and returning a private variable?

thanks
mark

 

[Jeff Johnson]

ah, but you don't have to new a string...but you do some other
objects...why is that?

Syntactic sugar.

x = "Hi there";

is just a shortcut for

x = new string("Hi there");

i guess the system is newing the variable behind the scenes basically?
Exactly.

so do you think the "variable-less" property style is more efficient than
creating and returning a private variable?

I don't know about "efficient." The same IL code should be getting created
behind the scenes if the ONLY thing you're doing is setting and returning
the backing variable. Ultimately it's about "good code" and "best practices"
and blah blah blah.

I like my backing variable. I like being able to shoot myself in the foot by
manipulating that variable outside the control of the setter. But that's
just me.

 

[mp]

ah, but you don't have to new a string...but you do some other
objects...why is that?

[...]

I like my backing variable. I like being able to shoot myself in the foot
by manipulating that variable outside the control of the setter. But
that's just me.

one can never have too many ways to f up.

 

[Arne Vajhøj]

trying to understand properties
normally i would create a private variable and return that in a get, assign
it in a set
class TestProperty
{
private List<string> _someList= new List<string>();
public List<string> SomeList { get{return _someList;} set{_someList
= value;} }
...}

i see in c# the type of property that doesn't use a variable (must create a
hidden var behind the scenes or something...)
class TestProperty
{
public string strProp { get; set; }
...}

It does create a hidden variable.

But it does not set it.

So it is equivalent to:

class TestProperty
{
private List<string> _someList; // = new List<string>();
public List<string> SomeList { get{return _someList;}
set{_someList = value;} }
...}

I got to wondering if I was wasting a variable by using the first (more
verbose) style
so i tried it with a list but that didn't work because (naturally) the list
was null

class TestProperty
{
public List<string> SomeList { get; set; }
public TestProperty()
{
}
public void Test()
{
// A first chance exception of type
'System.NullReferenceException'
SomeList.Add ("Test1");
}
}

Either the constructor needs to set SomeList.

Or the caller needs to set before calling Test.

yet with a string it does work...although a string is also an object so not
sure why i didn't get the same null reference exception

class TestProperty
{
public string strProp { get; set; }

public TestProperty()
{
}
public void Test()
{ //this works
strProp = "Test strprop";
}
}

appreciate any background or sites that explain why the difference...

This does not use the null reference but instead assigns
a valid reference.

i imagine if the class doesn't have to interact with the value during its
lifetime other than to receive a setting from client and return it when
asked, then the variable is of not much use...
but if the class in any method needs to manipulate the variable, then the
private var is useful(though it could probably access it's own property i
would guess...so i'm not sure about that either)

I think the most common case with a List would be to
set it in constructor and have a method that returns
an unmodifiable list and a method to add to the list.
Better encapsulation.

Arne

 

[Arne Vajhøj]

Syntactic sugar.

x = "Hi there";

is just a shortcut for

x = new string("Hi there");

Not really.

That constructor does not exist and if it did, then
it would create an extra object.

Arne

 

[Arne Vajhøj]

so do you think the "variable-less" property style is more efficient than
creating and returning a private variable?

No.

The difference will be insignificant.

Arne

 

[Arne Vajhøj]

I don't know about "efficient." The same IL code should be getting created
behind the scenes if the ONLY thing you're doing is setting and returning
the backing variable. Ultimately it's about "good code" and "best practices"
and blah blah blah.

I like my backing variable. I like being able to shoot myself in the foot by
manipulating that variable outside the control of the setter. But that's
just me.

Where the difference really shows up is of the property is
virtual and getting overridden in a sub class, then there
can be a functional difference between field and property.
In most cases I think the behavior of direct field access
will be least surprising.

Arne

 

[mp]

No.

The difference will be insignificant.

Arne

Arne,
Thanks for all your responses
Mark