Re: Properties


"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:12ijd02r04bba79@xxxxxxxxxxxxxxxxxxxxx
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> wrote in message
news:12ijbfmagtfj3f9@xxxxxxxxxxxxxxxxxxxxx
[...]
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 fucking 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?

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?


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.


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.


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.


.

Loading