Re: Properties


"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:12ij77sf763hd59@xxxxxxxxxxxxxxxxxxxxx
"Jon Slaughter" <Jon_Slaughter@xxxxxxxxxxx> wrote in message
news:12ij382ncl3or6c@xxxxxxxxxxxxxxxxxxxxx
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 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.






.

Relevant Pages

  • Re: C#, Windows Authentification & Windows API
    ... In the SDK the LogonUserEx is declared as ... DWORD dwLogonType, ... And your declaration seems to miss many params. ... > public string UserID; ...
    (microsoft.public.platformsdk.security)
  • Re: identifiers and modules
    ... Do you have a reason why a language should allow it? ... (let ((foo (transform-value foo))) ...)) ... working on a large nested function can easily use the wrong variable ... Given that allowing an inner declaration to override an outer ...
    (comp.lang.scheme)
  • Re: identifiers and modules
    ... Do you have a reason why a language should allow it? ... (let ((foo (transform-value foo))) ...)) ... working on a large nested function can easily use the wrong variable ... Given that allowing an inner declaration to override an outer ...
    (comp.lang.scheme)
  • Re: Scope of implied-do index
    ... but it seems like at least part of the reason. ... Implied DO variables with scope of the implied DO are one of my least ... but I can avoid using statement functions). ... is no place "reasonable" to put a declaration of them, ...
    (comp.lang.fortran)
  • RE: ActiveCell.Value copies unwanted currency format of source cel
    ... I just noticed something in my declaration of the variables but I'm not sure ... "JMB" wrote: ... decimals may be displayed). ... I cannot see any logical reason ...
    (microsoft.public.excel.programming)