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]

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]

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+(Employee 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+(Employee 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]]

"Jon Slaughter" <[email protected]> a écrit dans le message de (e-mail address removed)...

| > 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.Name; }
set
{
InnerObject.Name = value;
OnPropertyChanged("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]]

"Jon Slaughter" <[email protected]> a écrit dans le message de (e-mail address removed)...

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

"Jon Slaughter" <[email protected]> a écrit dans le message de (e-mail address removed)...

| 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

 

[Jon Slaughter]

"Jon Slaughter" <[email protected]> a écrit dans le message de
(e-mail address removed)...

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

"Jon Slaughter" <[email protected]> a écrit dans le message de
(e-mail address removed)...

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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]

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:

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]

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


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 programmatically 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]

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]

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


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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

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]

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

 

[Peter Duniho]

You know, before you write such a long winded post you should try and
understand what I said.

Believe me, I did. You're not making it easy. Excuse me for trying to
help.

Its not all your fault because I do expect anyone that replies to put a
little effort into figuring out what I asked.

The best question does not require "anyone that replies to put a little
effort into figuring out what you asked". Garbage in, garbage out. If you
don't ask a clear question, you won't get a clear answer.

Since you seem to be confused I'll break it down.

Yes, I am confused. However, you appear to be as well. Welcome to the
club.

Whats the difference between

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

This one compiles.

and

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

This one does not.

with a preprocesser that converts the second into the first?

There is no preprocessor 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.

Great. What will you call that field? At the very least, you cannot use
the same name that you've given your property (as you have done above). Why
do you think it is better to implicitly declare a field, rather than doing
it explicitly? How closely will the preprocessed code have to be to the
example you've provided in order to result in an implicitly defined field?
Can I write "get { return number + 1; }" and "set { number = value - 1; }"
and have your processor correctly generate the field? How many passes do
you expect your preprocessor to execute before it is sure that the field
being used in a property definition hasn't been already declared? Will your
preprocessor handle partial class declarations correctly?

And what benefit do you see in going to the trouble to write a preprocessor
just so you can save writing a line of code for the simplest case of
defining a property?

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

I don't see any reason at all that you can't accomplish what you want to, as
long as you do it correctly (there are lots of ways to do it incorrectly).
I just don't see the value in it. There are so many other uses for
properties, writing a preprocessor just so you can get out writing a single
line of code once in awhile seems like a big waste of time.

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

I don't doubt that.

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

You don't have to add a field declaration for a property to work. You only
need to do so if you want the property to work by accessing a field.
Furthermore, if you are so concerned with minimizing your typing, why
declare a property in the way you're showing us in the first place? Why not
just make a public field?

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.

Do you mean that you want to specify the modifier for the implicit field, as
"protected" instead of "private" (which would presumably be the default for
your preprocessor)? I agree, it's not impossible to do. I also don't see
how that's an issue at all. There are so many other pitfalls involved, this
seems like the least of your concerns.

The point is to loose the redundancy that exists....

There is no redundancy. A field is not the same thing as a property. One
declares a property for the purpose of declaring a property. One may or may
not declare a field to support that property. It all depends on the
implementation of the property.

why the hell did C# remove the necessary requirement in C++ for
prototypes? Because its redundant can be redudancy is error prone or
usless.

I'm not sure what "requirement in C++ for prototypes" you're talking about.
It's true that the Visual Studio C# environment does away with having to
explicitly include header files. But that's because it has a whole
different way of referencing code objects. Prototypes still exist...they
are just encapsulated differently.

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.

I never made such an argument. I have no idea why you think I did. The
name of a supporting field for a property is entirely irrelevant. You can
name the supporting field whatever you like.

I never said they were the same thing. The point is that a property
represents a field.

No. No. And did I mention? No.

IMHO, this is the crux of your misunderstanding. A property most
emphatically does NOT represent a field. It may well wrap a field, but as I
said before, this is the simplest, most trivial example of a property. It
is the least interesting, and a property is MUCH much more than that.

There need not be ANY field associated directly with a property, and even
when there is a field associated with a property, the property may (and
often will) do much more than just returning or assigning the value of that
field.

[...]
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)...

That is not "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.

I have not tried to say it cannot be done. I don't disagree that what you
want can be done. I just don't think doing it is useful, and I believe that
your desire to do it (and your belief that the authors of C# should have
done it) demonstrates a incorrect understanding of what a property is.

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.

It has everything to do with the "argument", such as it is. Personally, I
didn't realize we were having an argument. I was trying to help you
understanding the true difference between a field and a property, and I
believe the other respondents were too. Perhaps if you stopped viewing this
as an "argument", you could relax enough to take in the information being
offered.

A property might not be a field and a field might not be a property but
where theres a property theres a field

For the third time, this is NOT true. It is false to claim that "where
there's a property there's a field".

and hence theres no reason to declare a field when theres a property for
it.

The reason for declaring a field when there's a property for it is to tell
the compiler where and what the field being used in the property definition
is, if indeed a field IS being used in the property definition.

The point is that the conversion I have given is programmatically
identical and reduces redundancy. There might be other reasons why its not
good to do it that way but you have not given any.

I wasn't trying to. I was trying to explain to you the difference between a
field and a property, since that appeared to be the question you asked.

If you're looking for an answer to why you shouldn't write the preprocessor
you suggest, the only answer I have to that is that I think it'd be a waste
of time. But please, go right ahead and do it if you think it will help you
write your code.

That still doesn't mean that you understand the difference between a
property and a field.

Pete

 

[Gino]

Sometime you might want to have just a field to use internally which you
can.
And sometimes you might want to have somthing more complex.
There all just tools in the toolbox.

MenuList m_Menus;
public MenuList Menus
{
get
{
return m_Menus;
}
set
{
m_Menus = value;
if (m_Menus != null)
m_Menus.Parent = this;
}
}

 

[Peter Duniho]

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

It (or at least something like it) would work. There is no redundancy to
simplify, so no...it wouldn't accomplish that.

Several of you have mentioned that fields and properties are not the same
but the point is that properties "contain" fields.

Properties do not "contain" fields. They may use fields. But they don't
"contain" them. They are something entirely different from fields. A
property may use no fields. It may use one field. It may use many fields.
A property does not contain any field any more than any other method of a
class contains a field.

The class is what contains a field. A property is just a special-purpose
method in the class. It may or may not use one or more fields in the class.

I don't see any reason to have to explicitly declare them.

Why should I have to declare any variable most of the time? If I code:

for (i = 0; i < 100; i++)
{
}

Why should I have to declare "i" at all? Why can't the compiler just assume
I want it declared as an int and be done with it?

The fact is, ambiguity is bad. Clarity is good. And making languages that
support ambiguity can be hazardous and pointless.

The reason you explicitly declare fields used by a property is that the
compiler needs to know what the code in the property does. If you use an
undefined field in a property, the compiler has no idea what to do with
that. There may be some limited situations in which a compiler can infer
the type and usage of a field, but most of the time it can't. Adding that
inference to the language specification is a waste, and encouraging
programmers to write code that uses identifiers without defining them is
dangerous.

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.

You could also just write:

public string Name;

And be done with it. That does exactly what your preprocessed,
added-grammar property definition does.

Pete

 

[Jon Slaughter]

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

It (or at least something like it) would work. There is no redundancy to
simplify, so no...it wouldn't accomplish that.

Several of you have mentioned that fields and properties are not the same
but the point is that properties "contain" fields.

Properties do not "contain" fields. They may use fields. But they don't
"contain" them. They are something entirely different from fields. A
property may use no fields. It may use one field. It may use many
fields. A property does not contain any field any more than any other
method of a class contains a field.

whats the whole point of properties? You are using a definition of
properties that you created that is very narrow. It doesn't mean that the
definition of properties can't be expanded or cannot be called something
else. You are using a very limited and narrow use of properties and not
giving me any room. I could have called them mumbo jumbo and it still would
not make a difference.

From the camels mouth:

"Properties are members that provide a flexible mechanism to read, write, or
compute the values of private fields. "

(i.e., the whole ****ing point of properties, by this definition is to deal
with fields)

http://msdn2.microsoft.com/en-us/library/x9fsa0sw.aspx

You really not to stop being so dense and open up your mind a little. Its
like your convinced that you shoudl say potato a certain way and if anyone
else says it different than there wrong and your right.


I am not saying that one cannot use the other definition, or that there one
has to use properties in the way I defined them. I am talking about
extending the ability. If you want to create a new keyword to satisfy your
mind then so be it. I just think that the majority of properties tend to be
related to the field they modify(atleast by name). I am not saying that one
has to use the "implicit" field in my method or throw out the current way.

one can suppose that if you do not use the implicit field created by the
complier using the ".this" token then that field is not created. It also
doesn't mean you cannot use other fields.

for example, in the code on that page tey give the example:

private double seconds;

public double Hours
{
get { return seconds / 3600; }
set { seconds = value * 3600; }
}
}This is perfectly fine. the hours property, if we think about what I have
defined as a property, does not us the Hours.this so there is no internal
field for it(and hence no wasted space) and the syntax is perfectly fine the
way it is. (it would compile fine as would any current C# "implementation"
of a property).

The class is what contains a field. A property is just a special-purpose
method in the class. It may or may not use one or more fields in the
class.

it doesn't matter what it is. If it doesn't use a field then why call it a
property and not a method?

Why should I have to declare any variable most of the time? If I code:

for (i = 0; i < 100; i++)
{
}

Why should I have to declare "i" at all? Why can't the compiler just
assume I want it declared as an int and be done with it?

this is totally different. You are using i for the first time and there is
no unambiguous way to extract what you mean.

The fact is, ambiguity is bad. Clarity is good. And making languages
that support ambiguity can be hazardous and pointless.

um, its not ambiguous to define it as I have and if it is then you should
point out why.

The reason you explicitly declare fields used by a property is that the
compiler needs to know what the code in the property does. If you use an
undefined field in a property, the compiler has no idea what to do with
that. There may be some limited situations in which a compiler can infer
the type and usage of a field, but most of the time it can't. Adding that
inference to the language specification is a waste, and encouraging
programmers to write code that uses identifiers without defining them is
dangerous.

sheesh. There are so many counter examples to this. You have a very limited
understanding of how a complier works. You also are not understanding what I
mean because the last sentence is completely invalid w.r.t to how I have
defined things.

You could also just write:

public string Name;

And be done with it. That does exactly what your preprocessed,
added-grammar property definition does.

um. so you have no getter and setter and hence no encapsulation, no checking
or special purpose handling... i.e., no property but just a field. You are
giving irrelvant examples.


You really should think about what you say. Maybe I'm just not making sense
but it really is a simple concept. I'm not asking the programmer to change
anything he has done before or have him use "undefined" variables or
anything like that.

 

[Jon Slaughter]

Sometime you might want to have just a field to use internally which you
can.
And sometimes you might want to have somthing more complex.
There all just tools in the toolbox.

MenuList m_Menus;
public MenuList Menus
{
get
{
return m_Menus;
}
set
{
m_Menus = value;
if (m_Menus != null)
m_Menus.Parent = this;
}
}

yes, this is what I call a simple property. I am not talking about
redefining or breaking the current implementation of "properties" but
extending the ability to write less code. Maybe this idea is just not grand
enough to be added the grammar though.