Stupid error with get/set on properties

[K Viltersten]

Can someone, please, tell me what is wrong
with this code?! I get stuck on the "set"
method of the property.

public class Start
{[STAThread]
public static void Main ()
{ Something some1 = new Something ();
Something some2 = some1.doSome (); }}

class Something
{public Something () : this (1) { }
public Something (Something p) : this (p.Some) { }
public Something (byte s) { this.Some = s; }

public byte Some
{ get { return this.Some; }
set { this.Some = value; }}
public Something doSome ()
{ return new Something (2); }}

The program runs well when i use the default
definition of get/set as:

public byte Some { get; set; }

but one certainly need to be able to affect
what's being done there. I've been looking at
this for a few days. Either i'm slow or blind,
i can't see the error!

 

[Jon Skeet [C# MVP]]

Can someone, please, tell me what is wrong
with this code?! I get stuck on the "set"
method of the property.

public byte Some
{
get { return this.Some; }
set { this.Some = value; }
}

These calls are recursive - and you haven't declared any actual
storage.

Remember that the properties are just method calls in disguise. As soon
as I rewrite the properties this way, I'm sure you'll see why it
doesn't work:

public byte GetSome()
{
return GetSome();
}

public void SetSome(byte value)
{
SetSome(value);
}

You probably *meant* it to be something like this:

// Field backing the property
private byte some;
// Property
public byte Some
{
// Note case changes
get { return this.some; }
set { this.some = value; }
}

 

[Jon Skeet [C# MVP]]

Ill-informed it is, then!

I was under impression that the whole thing with
properties is not to use the setter/getter syntax:

int number;
public int setNumber (int n) {this.number = n;}
public void getNumber () {return this.number;}

The point of properties is to make syntax simpler, so you can write:

x.Foo.Bar.Baz

instead of

x.getFoo().getBar().getBaz()

That's really all it is.

but on your reply it sounds that it's basically the same
as in C++/Java. Do we have "properties" just for the
same of having something other than "instance
variables"?

The point of properties is that they expose data as part of the API
without exposing the details of how that data is stored. A field is
part of the implementation of a class - a (non-private) property is
part of the API.

In that case, i'll be off to kick my friend
who swore that i shouldn't use "byte _info" to carry
the contents presented by "Info"-property.

Well, if you can use an automatic property, you might as well do so
(and the compiler will autogenerate a field). But if you're writing the
property manually, you should absolutely use a field (unless it could
be a more esoteric property, e.g. one which reads its data from a
file).

 

[K Viltersten]

No offense, but I vote for "slow". Or at least (and

maybe more polite), ill-informed.

Ill-informed it is, then!

I was under impression that the whole thing with
properties is not to use the setter/getter syntax:

int number;
public int setNumber (int n) {this.number = n;}
public void getNumber () {return this.number;}

but on your reply it sounds that it's basically the same
as in C++/Java. Do we have "properties" just for the
same of having something other than "instance
variables"? In that case, i'll be off to kick my friend
who swore that i shouldn't use "byte _info" to carry
the contents presented by "Info"-property.

Thanks a 10^3 for the answer!

 

[K Viltersten]

I was under impression that the whole thing with

The point of properties is to make syntax simpler,
so you can write:

x.Foo.Bar.Baz

instead of

x.getFoo().getBar().getBaz()

That's really all it is.

Ah, got it. Thanks.

 

[Jon Skeet [C# MVP]]

[...]
Well, if you can use an automatic property, you might as well do so
(and the compiler will autogenerate a field). But if you're writing the
property manually, you should absolutely use a field (unless it could
be a more esoteric property, e.g. one which reads its data from a
file).

I think this is worth emphasizing: I think the phrase "should absolutely"
is misleading, since the examples of "a more esoteric property" are
numerous, and especially since the one example provided seems to imply
that some dedicated state is still stored somewhere.

Agreed in every respect.