Properties

[Peter Duniho]

Re: Properties

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

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 "requiremen t 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 misunderstandin g. 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 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.

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]

Re: Properties

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;
}
}

"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; }
}
>
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.)
>
>
>

[Peter Duniho]

Re: Properties

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

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

Re: Properties


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

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

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

[Jon Slaughter]

Re: Properties


"Gino" <someone@micros oft.comwrote in message
news:unxOEo06GH A.3452@TK2MSFTN GP05.phx.gbl...

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.

[Jon Slaughter]

Re: Properties


"Arne Vajhøj" <arne@vajhoej.d kwrote in message
news:b0iWg.2080 2$2g4.2103@duke read09...

Jon Slaughter wrote:

>"Arne Vajhøj" <arne@vajhoej.d kwrote in message
>news:kMgWg.207 99$2g4.18673@du keread09...

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

What is invalid now is invalid later. C# use to not use generics and by your
logic one should never have implemented it because a the time it was invalid
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
>demonstratio n purposes its just fine)...

>
What would you create from:
>
public string Name
{
set { a = value; b = value/2; c = d + value;}
}
>
?
>
Create 4 fields ?
>

Nope, there would be only one field creates. a field that is used like
Name.this. (or even maybe this.Name would work).

a,b,c,d have nothing to do with the property name's definition.

You really don't understand what I'm talking about or you wouldn't ask this
kinda question.

[Jon Slaughter]

Re: Properties


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

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

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

but if you want to help then you must really think about what I want. You
are not understanding it either because of me or because of yourself.... in
any case you should ask to clarify instead of assuming.

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

I think I mentioned this. I'm not perfect.

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

I'm not, really ;) This is a simple concept that I would bet makes complete
sense. There may be some obscure reason why it wasn't done and thats what
I'm tryign to figure out. But you guys really don't seem to have a clue
about what I'm talking about.

>

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

lol. and C# didn't exist 10 years ago and neither did bill gate 100 years
ago... whats your point? I really hope you are being facetious.

>with a preprocesser that converts the second into the first?

>
There is no preprocessor that converts the second into the first.

Sure there is, I haven't created it yet. You are really being dense.
tomarrow doesn't exist so by your logic we shouldn't be here today.

>

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

I mentioned the first part in another post. As far as the later stuff is
concerned it all depends on how much effort I want to put into it. If I
wanted a simple search and replace using some context free grammar then it
wouldn't be to hard. But again, you are not understanding what I'm after
because a property cannot exist in more than one definition.

just so you can save writing a line of code for the simplest case of
defining a property?
>

well, thats a valid point but there are also other things I would like to
do. I did do this for C++ to add the ability to have properties. It worked
out nicely. Its not a line of code either when you have many properties.

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

maybe. But just because its a waste to you doesn't necessarily mean its a
waste. Sure, it might be but you don't know that. I would also like to
implement the ability to do symmetric binary operators so one doesn't have
to duplicate code for < and == !=. Theres no reason to do that as they
obviously are the same things.

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

omg... now I guess you are calling me a lier. ok, I guess theres no more
talking to you then.

[Dave Sexton]

Re: Properties

Hi Jon,

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.

But you're not writing less code:

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

private void Method(string something)
{
Name".this" = something.ToLow er();
}

That is more typing or could potentially be more typing than just:

private string Name;

Obviously you will need some mechanism such as ".this", as you suggested, which is going to add at least 1 (probably 2 or more)
characters each time the hidden field is referenced in code, which happens quite often in my coding practices. Also, the keyword
"property" is a bit wordy. I prefer C#, not VB ;)

IMO, your idea doesn't add any value to me as a developer. I lose flexibility, and trade it for a facade of "less code". How do
you propose that I add attributes to that field? Can I change it's static modifier? How about access modifiers? What about it's
name? All of these are C# features that I use and would not like to give them up. I understand that you aren't attempting to
replace this functionality or remove it, but I like having it at my disposal all the time.

HTH

--
Dave Sexton

"Jon Slaughter" <Jon_Slaughter@ Hotmail.comwrot e in message news:12ijh6f9m3 88n04@corp.supe rnews.com...

>
"Gino" <someone@micros oft.comwrote in message news:unxOEo06GH A.3452@TK2MSFTN GP05.phx.gbl...

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

[Cor Ligthert [MVP]]

Re: Properties

Jon,

Maybe you are right, but I would prefer than.

Public string Name
get {return emaN;}
set {return emaN = value;}

I hope that you see that I am not serious.

Why it should be "name" with an undercase while I maybe have already used
that in the program.

Cor


"Jon Slaughter" <Jon_Slaughter@ Hotmail.comschr eef in bericht
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.
>
Thanks,
Jon
>
>
>
>
>
>
>
>

[Dave Sexton]

Re: Properties

lol, in my example "private string Name", I of course mean, "private string name"

-- sorry

--
Dave Sexton

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message news:%234daQe16 GHA.4604@TK2MSF TNGP03.phx.gbl. ..

Hi Jon,
>

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

>
But you're not writing less code:
>
public "property" string Name
{
get { return Name".this"; }
set { Name".this" = value; }
}
>
private void Method(string something)
{
Name".this" = something.ToLow er();
}
>
That is more typing or could potentially be more typing than just:
>
private string Name;
>
Obviously you will need some mechanism such as ".this", as you suggested, which is going to add at least 1 (probably 2 or more)
characters each time the hidden field is referenced in code, which happens quite often in my coding practices. Also, the keyword
"property" is a bit wordy. I prefer C#, not VB ;)
>
IMO, your idea doesn't add any value to me as a developer. I lose flexibility, and trade it for a facade of "less code". How do
you propose that I add attributes to that field? Can I change it's static modifier? How about access modifiers? What about it's
name? All of these are C# features that I use and would not like to give them up. I understand that you aren't attempting to
replace this functionality or remove it, but I like having it at my disposal all the time.
>
HTH
>
--
Dave Sexton
>
"Jon Slaughter" <Jon_Slaughter@ Hotmail.comwrot e in message news:12ijh6f9m3 88n04@corp.supe rnews.com...

>>
>"Gino" <someone@micros oft.comwrote in message news:unxOEo06GH A.3452@TK2MSFTN GP05.phx.gbl...

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

>
>

[Peter Duniho]

Re: Properties

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

but if you want to help then you must really think about what I want.

The point is, if you really want help, you should do a better job of not
making those who would help you think too hard.

[...]

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

>
omg... now I guess you are calling me a lier. ok, I guess theres no more
talking to you then.

Let's see. I wrote that I do NOT doubt you, and you read it to mean that I
am calling you a "lier [sic]"?

If that's the kind of reading comprehension you're applying to the rest of
this thread, I think I can see where at least part of the problem lies.

In any case, I'm done trying to help you. You claim to be asking for advice
and answers, but in thread after thread, what you really seem to be looking
for is a fight. You'll have to find someone else to provide that...I'm not
into wasting my time.

Pete

[Jon Slaughter]

Re: Properties


"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%234daQe16 GHA.4604@TK2MSF TNGP03.phx.gbl. ..

Hi Jon,
>

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

>
But you're not writing less code:
>

Theres no need to take me literally. Surely you can see also that it is less
error prone(well, atleast for the most part).

public "property" string Name
{
get { return Name".this"; }
set { Name".this" = value; }
}
>
private void Method(string something)
{
Name".this" = something.ToLow er();
}
>
That is more typing or could potentially be more typing than just:
>

If your so worried about typing then just use an @ simple or something to
suggest that.

private string Name;
>
Obviously you will need some mechanism such as ".this", as you suggested,
which is going to add at least 1 (probably 2 or more) characters each time
the hidden field is referenced in code, which happens quite often in my
coding practices. Also, the keyword "property" is a bit wordy. I prefer
C#, not VB ;)
>

yeah, but I'm not so worry about how much more letters one has to type if
the benefits outway it. adding a few more characters are fine if its clearer
and less error prone. Remember, your probably not going to use the .this
field out side of the property anyways so it could be less code depending on
how you write it(and you could use a temp variable as an alias for the field
property.

IMO, your idea doesn't add any value to me as a developer. I lose
flexibility, and trade it for a facade of "less code". How do you propose
that I add attributes to that field? Can I change it's static modifier?
How about access modifiers? What about it's name? All of these are C#
features that I use and would not like to give them up. I understand that
you aren't attempting to replace this functionality or remove it, but I
like having it at my disposal all the time.
>

Well, you mention some good things but I never said you had to give them
up(which I mentioned on top).

You can do exactly what you do and it will work. I'm not changing anything
but adding to it and what I add doesn't change any pre-existing syntax or
grammar.

This really just makes it easier and less error prone(not so much error
prone as it is consistancy).

if I want to do a quick getter and setter I do not have to create the
"explicit" field as one will already be supplied to me. If I choose to
create an explicit field than I can and I can do whatever I want with it as
I normally can do.

Ofcours would could add the ability to do all the things you mentioned in
the property itself but then it becomes more ambiguous and more error prone
and one would use the original method.

I would imagine that the majority of properties are simply accessors with
"bounds" checking and one doesn't really need any of the features you
mentioned and hence my idea would be less ambiguous/error prone and "less"
code. But again, in those few times I need something special I can just use
the original C# syntax to get it.

Now the best argument I have heard against it is simply that it might not be
worth doing. i.e., its really does not save all that much. Thats fine and
thats a valid argument. I didn't say that it needed to be implemented but
was more asking about why it wasn't as if theres some technical reason. That
reason might simply be what I just stated or it could be some more
complicated.

[Jon Slaughter]

Re: Properties


"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:u39sZh16GH A.1012@TK2MSFTN GP05.phx.gbl...

lol, in my example "private string Name", I of course mean, "private
string name"
>
-- sorry

Don't worry, I'm not going to bitch at you about it. It happens to all the
mere mortals that visit these news groups.... ofcourse theres not to many of
us here.

[chanmm]

Re: Properties

When we learn OOP in C++ in school days remember we have something call
setter and getter? So it is just a simple OOP concept. Rather I need to
appreciate .Net framework actually making it kind of unique for that
concept.

chanmm

"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.
>
Thanks,
Jon
>
>
>
>
>
>
>
>

[KH]

RE: Properties

You haven't read this have you?

http://www.amazon.com/How-Win-Friends-Influence-People/dp/0671723650

"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; }
}
>
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
>
>
>
>
>
>
>
>
>