Properties

[Jon Slaughter]

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

In the above, why doesn't C# just allow one to create a single directive to
make a property?

why not something like

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

Why the need to declare the same thing basically twice? If, say there was no
block associated with the variable then its assumed to be a field instead of
a property.

i.e.

public string Name; works and is a "Field".

while

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

is a property.

Thanks,
Jon

[Jon Slaughter]

Re: Properties


"Jon Slaughter" <Jon_Slaughter@ Hotmail.comwrot e in message
news:12iiv3j3ro 2b8ea@corp.supe rnews.com...

private string name;
public string Name
{
get { return name; }
set { name = value; }
}
>
In the above, why doesn't C# just allow one to create a single directive
to make a property?
>
why not something like
>
public string Name
{
get { return name; }
set { name = value; }
}
>
Why the need to declare the same thing basically twice? If, say there was
no block associated with the variable then its assumed to be a field
instead of a property.
>
i.e.
>
public string Name; works and is a "Field".
>
while
>
public string Name
{
get { return name; }
set { name = value; }
}
>
is a property.
>

I guess also that one might, for some reason, what "direct" access to the
field. Maybe something like Name.this lets you get at it incase you want to
bypass the set and get in class.

[Jon Slaughter]

Re: Properties

It seems it would also be nice to somehow create a symmetric binary operator
without having to create two copies of the same thing. i.e.

public static Employee operator+(Emplo yee employee, Bonus bonus)
{
employee.Salary = employee.Salary + bonus.Amount;
return employee;
}

public static Employee operator+(Bonus bonus, Employee employee)
{
employee.Salary = employee.Salary + bonus.Amount;
return employee;
}

seems like a waste of typing and error prone. Why not have some keyword to
save the hassle?

e.g.,


public static Employee symmetric operator+(Emplo yee employee, Bonus
bonus)
{
employee.Salary = employee.Salary + bonus.Amount;
return employee;
}

I thought C# was pretty good but it seems that it still has a bit to go. I
guess I have to make a preprocessor to add these abilities ;/

[Joanna Carter [TeamB]]

Re: Properties

"Jon Slaughter" <Jon_Slaughter@ Hotmail.coma écrit dans le message de news:
12iiv9729r58hba @corp.supernews .com...

| Why the need to declare the same thing basically twice? If, say there
was
| no block associated with the variable then its assumed to be a field
| instead of a property.

Because a property is not a field, even though it can be addressed as if it
were a field. You cannot limit a field to read-only or even write-only, like
you can with a property; a field cannot encapsulate the side-effects of
setting itself like you can with a property; a field cannot encapsulate the
conversion of, say, an integer field to a string like you can with a
property

| public string Name; works and is a "Field".
| >
| while
| >
| public string Name
| {
| get { return name; }
| set { name = value; }
| }

But I could also do :

public string Name
{
get { return InnerObject.Nam e; }
set
{
InnerObject.Nam e = value;
OnPropertyChang ed("Name");
}
}

| I guess also that one might, for some reason, what "direct" access to the
| field. Maybe something like Name.this lets you get at it incase you want
to
| bypass the set and get in class.

When working in a class it is usual to access the field whlst only allowing
access from outside via the property.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Joanna Carter [TeamB]]

Re: Properties

"Jon Slaughter" <Jon_Slaughter@ Hotmail.coma écrit dans le message de news:
12iiv3j3ro2b8ea @corp.supernews .com...

| private string name;
| public string Name
| {
| get { return name; }
| set { name = value; }
| }
|
| Why the need to declare the same thing basically twice? If, say there was
no
| block associated with the variable then its assumed to be a field instead
of
| a property.

You are not declaring the same thing twice; name is a field, Name is a
property, there is not necessarily a one-to-one relationship. See my other
reply for more options.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Joanna Carter [TeamB]]

Re: Properties

"Jon Slaughter" <Jon_Slaughter@ Hotmail.coma écrit dans le message de news:
12iivvv4t5d100e @corp.supernews .com...

| I thought C# was pretty good but it seems that it still has a bit to go.
I
| guess I have to make a preprocessor to add these abilities ;/

I guess you are looking for a Utopian language that may never exist. All
languages have their shortfalls, but also their advantages. Why not write
your own language and submit it for community approval, I'm sure you will do
a better job than MS, Borland, Stroustroup, etc have done so far :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Jon Slaughter]

Re: Properties


"Joanna Carter [TeamB]" <joanna@not.for .spamwrote in message
news:uRmH%23xy6 GHA.348@TK2MSFT NGP02.phx.gbl.. .

"Jon Slaughter" <Jon_Slaughter@ Hotmail.coma écrit dans le message de
news:
12iiv9729r58hba @corp.supernews .com...
>
| Why the need to declare the same thing basically twice? If, say there
was
| no block associated with the variable then its assumed to be a field
| instead of a property.
>
Because a property is not a field, even though it can be addressed as if
it
were a field. You cannot limit a field to read-only or even write-only,
like
you can with a property; a field cannot encapsulate the side-effects of
setting itself like you can with a property; a field cannot encapsulate
the
conversion of, say, an integer field to a string like you can with a
property
>

but you can easily switch between a declaration of a field and a property by
just adding a body. These concepts are disjoin and so there is no ambiguity.

[Jon Slaughter]

Re: Properties


"Joanna Carter [TeamB]" <joanna@not.for .spamwrote in message
news:%23NDg%23x y6GHA.348@TK2MS FTNGP02.phx.gbl ...

"Jon Slaughter" <Jon_Slaughter@ Hotmail.coma écrit dans le message de
news:
12iiv3j3ro2b8ea @corp.supernews .com...
>
| private string name;
| public string Name
| {
| get { return name; }
| set { name = value; }
| }
|
| Why the need to declare the same thing basically twice? If, say there
was
no
| block associated with the variable then its assumed to be a field
instead
of
| a property.
>
You are not declaring the same thing twice; name is a field, Name is a
property, there is not necessarily a one-to-one relationship. See my other
reply for more options.
>

Um, I did and you didn't state anything that was useful.

A field isn't a property. So what, I never said they were. The fact is,
AFAIK, one can distinguish a field from a property simply by having a block
after the decleration of the field(i.e., now its a property). If this is not
the case then obviously you can't.

[Arne Vajhøj]

Re: Properties

Jon Slaughter wrote:

private string name;
public string Name
{
get { return name; }
set { name = value; }
}
>
In the above, why doesn't C# just allow one to create a single directive to
make a property?
>
why not something like
>
public string Name
{
get { return name; }
set { name = value; }
}

A property and a field is two different things.

There does not need to be a 1:1 relation ship between them.

And the names of the property and the field does not need
to follow the standard naming convention.

If a certain type of methods like properties really is
started to created fields for all undeclared names used
within them, then it would become rather chaotic.

Arne

[Peter Duniho]

Re: Properties

"Jon Slaughter" <Jon_Slaughter@ Hotmail.comwrot e in message
news:12ij382ncl 3or6c@corp.supe rnews.com...

>You are not declaring the same thing twice; name is a field, Name is a
>property, there is not necessarily a one-to-one relationship. See my
>other
>reply for more options.

>
Um, I did and you didn't state anything that was useful.

I thought her reply was reasonably useful. Perhaps a better response would
be "you didn't state anything that I found useful" (where the "I" refers to
you).

A field isn't a property. So what, I never said they were.

You kind of did, IMHO. You wrote that in the first example you provided,
you are "declaring the same thing basically twice". Since one of the
declarations is a field, and the other is a property, that statement seems
to me to say that a field is the same as a property.

I believe that to be the logical conclusion of your statement. You've shown
us two different things, and have said that including declarations of both
things is "declaring the same thing basically twice". The phrase "same
thing" *seems* to be referring to those two things, meaning you've said that
those two things are in fact the same thing.

If that's not what you meant to say, perhaps you could clarify your
statement for us.

The fact is, AFAIK, one can distinguish a field from a property simply by
having a block after the decleration of the field(i.e., now its a
property). If this is not the case then obviously you can't.

One can distinguish a field from a property no matter where their
declarations appear, and just as you describe. A field is declared using
the syntax for a field, where you have a type and a name, and optionally
some modifiers ("private", "static", "public", etc.), terminated by a
semicolon. A property is declared using the syntax for a property, where
you have all of those things followed by a braced block that contains either
a "get" method, a "set" method, or both.

You could just as easily write:

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

There's no ambiguity, nor is there one thing being declared twice.

As far as your conclusion goes that the requirement that you explicitly
define both the field and the property is superfluous, I remain unconvinced.
A field and a property each do very specific things, and are not the same
things at all. I believe that's what Joanna was saying.

In particular, a field is a place to store data. It is just a variable that
goes along with the class.

On the other hand, a property is a very specific type of method. It's not
data storage at all. It's a way of retrieving and assigning data. Where
that data is actually stored, or even IF it is actually stored is completely
up to the author of the property. The example property you've given is the
most trivial implementation of a property, but it is by no means the only
way to implement a property, and it's not really even the most interesting
way to implement a property (even if it is one of the more common ways).

A property may rely on a specific field to store the data associated with
the property, or a property may apply some other logic, such as taking a
single value passed in and somehow applying it to multiple things, or to
some property of a class contained within the class. Retrieving a property
may aggregate data from multiple fields or other sources. A property could
even translate into some kind of i/o, like writing and reading to and from a
file.

Basically, a property is an abstraction presented to the user of a class.
It may or may not have a 1-to-1 correlation to some field within the class.

Looking at your original post, you don't seem to correctly understand how
the declarations of fields and properties work. Specifically, you ask for
behavior that already happens:

"Jon Slaughter" <Jon_Slaughter@ Hotmail.comwrot e in message
news:12iiv3j3ro 2b8ea@corp.supe rnews.com...

Why the need to declare the same thing basically twice? If, say there was
no block associated with the variable then its assumed to be a field
instead of a property.

That's exactly how C# works, actually.

i.e.
>
public string Name; works and is a "Field".

This is what C# does. If you declare an identifier as you've shown there,
it's a field.

while
>
public string Name
{
get { return name; }
set { name = value; }
}
>
is a property.

Again, that is what C# does. If you declare an identifier as you've shown
there, it's a property. However, note that in your second example, your
property relies on a field also being declared, with the name "name".

It seems as though you may be confused by examples in which the field is
always followed immediately by a property declared to provide access to that
field. This is not required, and those examples may be misleading you into
thinking of the two as being more tightly integrated than they actually are.

Pete

[Jon Slaughter]

Re: Properties


"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:12ij77sf76 3hd59@corp.supe rnews.com...

"Jon Slaughter" <Jon_Slaughter@ Hotmail.comwrot e in message
news:12ij382ncl 3or6c@corp.supe rnews.com...

>>You are not declaring the same thing twice; name is a field, Name is a
>>property, there is not necessarily a one-to-one relationship. See my
>>other
>>reply for more options.

>>
>Um, I did and you didn't state anything that was useful.

>
I thought her reply was reasonably useful. Perhaps a better response
would be "you didn't state anything that I found useful" (where the "I"
refers to you).
>

>A field isn't a property. So what, I never said they were.

>
You kind of did, IMHO. You wrote that in the first example you provided,
you are "declaring the same thing basically twice". Since one of the
declarations is a field, and the other is a property, that statement seems

<snip>

You know, before you write such a long winded post you should try and
understand what I said. Its not all your fault because I do expect anyone
that replies to put a little effort into figuring out what I asked. Since
you seem to be confused I'll break it down.


Whats the difference between

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

and

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

with a preprocesser that converts the second into the first? There is a
direct correspondece. I could easily write(and probably will) a preprocesser
that will search for "properties " and add a field. It will work fine and
there should be no issues(if there are then you need to state some syntatic
or semanitic reason why it will not work).

This is very similar to when I wrote a preprocessor to add properties to
C++. it is actually very similer.

The fact of the matter is that by adding having to add a field declaration
for a property to work is redundant(and if not then explain why). The only
case that I can think of is when you want the field used by the property to
be protected... but then one could change the grammar slightly to allow for
that. Its not impossible to do and is quite easy. The point is to loose the
redundancy that exists.... why the hell did C# remove the necessary
requirement in C++ for prototypes? Because its redundant can be redudancy is
error prone or usless.

About your arguments that the property doesn't have to work with a field
with the same name is quite useless because in almost all cases they are the
same except for case or very similar.

You could just as easily write:

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

There's no ambiguity, nor is there one thing being declared twice.

As far as your conclusion goes that the requirement that you explicitly
define both the field and the property is superfluous, I remain
unconvinced. A field and a property each do very specific things, and are
not the same things at all. I believe that's what Joanna was saying.

I never said they were the same thing. The point is that a property
represents a field. The field is implicit when you have a property so there
is no need to make an explicit declaration. The complier can easily assume
that there exists a field with the property and add it implicitly. The only
thing needed is a way to access the implicit field. I proposed a possible
way(not something that is necessarily cononical but nontheless works).

again, the point is that when I declare a property the compiler can
unambigulous determine that a field is being used(because thats the whole
point of properties)... since it can then it can handle the redundancy
implicitly. There is no reason that you have given why this cannot be done.
If, say, its not grammatically possible because, say, C# uses a context free
grammar and it would require a context sensitive grammar then that is a
reason(ofcourse thats not the case)... but saying things like a field is not
a property is completely off the point and has nothing to do with the
argument. A property might not be a field and a field might not be a
property but where theres a property theres a field and hence theres no
reason to declare a field when theres a property for it. The point is that
the conversion I have given is programmaticall y identical and reduces
redundancy. There might be other reasons why its not good to do it that way
but you have not given any.

[Jon Slaughter]

Re: Properties


"Arne Vajhøj" <arne@vajhoej.d kwrote in message
news:kMgWg.2079 9$2g4.18673@duk eread09...

Jon Slaughter wrote:

> private string name;
> public string Name
> {
> get { return name; }
> set { name = value; }
> }
>>
>In the above, why doesn't C# just allow one to create a single directive
>to make a property?
>>
>why not something like
>>
> public string Name
> {
> get { return name; }
> set { name = value; }
> }

>
A property and a field is two different things.
>
There does not need to be a 1:1 relation ship between them.
>

I never said they were the same or the were 1:1.

And the names of the property and the field does not need
to follow the standard naming convention.

So... that has nothing to do with anything. How many times does someone
create a field and a property that uses two different names(excluding case)
or drastically different names?

>
If a certain type of methods like properties really is
started to created fields for all undeclared names used
within them, then it would become rather chaotic.
>

It would? give an example so I can shoot it down. i.e., its very simple.

You createa property such as

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

The compiler creates an implicit field. We reference this field directly by
some method, say, Name.this(maybe not the best way but for demonstration
purposes its just fine)...

so how is this any different from manually typing

private string Name.this;
public string Name
{
get { return Name.this; }
set { Name.this = value; }
}

? (sure the it is invalid but proves the point. ) (if you still don't get it
then I don't know what to say.)

[Jon Slaughter]

Re: Properties


"Jon Slaughter" <Jon_Slaughter@ Hotmail.comwrot e in message
news:12ija7efv2 au437@corp.supe rnews.com...

>
"Arne Vajhøj" <arne@vajhoej.d kwrote in message
news:kMgWg.2079 9$2g4.18673@duk eread09...

>Jon Slaughter wrote:

>> private string name;
>> public string Name
>> {
>> get { return name; }
>> set { name = value; }
>> }
>>>
>>In the above, why doesn't C# just allow one to create a single directive
>>to make a property?
>>>
>>why not something like
>>>
>> public string Name
>> {
>> get { return name; }
>> set { name = value; }
>> }

>>
>A property and a field is two different things.
>>
>There does not need to be a 1:1 relation ship between them.
>>

I never said they were the same or the were 1:1.
>

>And the names of the property and the field does not need
>to follow the standard naming convention.

>
So... that has nothing to do with anything. How many times does someone
create a field and a property that uses two different names(excluding
case) or drastically different names?
>

>>
>If a certain type of methods like properties really is
>started to created fields for all undeclared names used
>within them, then it would become rather chaotic.
>>

>
It would? give an example so I can shoot it down. i.e., its very simple.
>
You createa property such as
>
public string Name
{
get { return Name; }
set { Name = value; }
}
>

public string Name
{
get { return Name.this; }
set { Name.this = value; }
}

The compiler creates an implicit field. We reference this field directly
by some method, say, Name.this(maybe not the best way but for
demonstration purposes its just fine)...
>
so how is this any different from manually typing
>
private string Name.this;
public string Name
{
get { return Name.this; }
set { Name.this = value; }
}
>
? (sure the it is invalid but proves the point. ) (if you still don't get
it then I don't know what to say.)
>
>
>

[Arne Vajhøj]

Re: Properties

Jon Slaughter wrote:

"Arne Vajhøj" <arne@vajhoej.d kwrote in message
news:kMgWg.2079 9$2g4.18673@duk eread09...

>And the names of the property and the field does not need
>to follow the standard naming convention.

>
So... that has nothing to do with anything. How many times does someone
create a field and a property that uses two different names(excluding case)
or drastically different names?

It has everything to do with it.

It is valid C#.

>If a certain type of methods like properties really is
>started to created fields for all undeclared names used
>within them, then it would become rather chaotic.

>
It would? give an example so I can shoot it down. i.e., its very simple.
>
You createa property such as
>
public string Name
{
get { return Name; }
set { Name = value; }
}
>
The compiler creates an implicit field. We reference this field directly by
some method, say, Name.this(maybe not the best way but for demonstration
purposes its just fine)...

What would you create from:

public string Name
{
set { a = value; b = value/2; c = d + value;}
}

?

Create 4 fields ?

so how is this any different from manually typing
>
private string Name.this;
public string Name
{
get { return Name.this; }
set { Name.this = value; }
}
>
? (sure the it is invalid but proves the point. )

And ?

One case where it makes sense does neither prove nor indicate
that it makes sense in all cases.

(if you still don't get it then I don't know what to say.)

Try counting how many people think it is a good idea and how
many think it is not.

Arne

PS: I am not so fond of the field-property coupling myself,
but your solution is not a good solution.

[Jon Slaughter]

Re: Properties

If, suppose, you can explain why the follow will not work then I might
understand some of you.

I will "extend" the C# grammar by creating a parser. The parser inputs a
super set of the grammar of C# and returns compatible C# code.

Heres how the simplified parser works(would actually do more if
implemented):

1. Looks for any properties.
2. Get the name of the property.
3. Creates a private field in the same class as the property and appends a
random string to the the name of property and use that for the field.
4. looks for any references to properties and the use the .this quantifier.
If found replaces these tokens with the name of the field generated in 3.
5. repeat until done.


Example.

Extended C#:
public string Name
{
get { return Name.this }
set { Name.this = value; }
}

after parse, changed text in brackets:

private string Name398492893;
public string Name
{
get { return Name398492893 }
set { Name398492893 = value; }
}


Is there any reason why this would not work and not simplify the redudancy
in creating properties?

Several of you have mentioned that fields and properties are not the same
but the point is that properties "contain" fields. I don't see any reason to
have to explicitly declare them. We could, say, define a keyword called
property that does just this... i.e., the exact same code above but add the
word property to the declaration:


public property string Name
{
get { return Name.this }
set { Name.this = value; }
}

and then do the parsing to convert.

A property has an implicit field attached to it and we can reference this
using the ".this" syntax(or some other if this is not good). We don't need
an explicit name for it because it is almost always redudant(i.e., creating
the field explicitly is useless when it really is just part of a property).