Properties

[Dave Sexton]

Re: Properties

Hi Jon,

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

I think there is a need to take you literally. Please write what you really mean, literally :)

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

>That is more typing or could potentially be more typing than just:
>private string name; [FIX: "Name"]

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.

What are the other benefits? Less error prone means what exactly?

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.

>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

If I can't access the field then I'll have to access the property. I'd rather have the flexibility to avoid properties that perform
error checking or examine the state of the object, for example. Those properties are used quite often in my coding experience.
i.e., Properties that are useful ;)

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.

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

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

So the only benefit so far is consistancy, and no longer error reduction or less code?
So, what does consistancy mean exactly?

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.

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

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.

Could you please clarify this statement?

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.

I disagree with your assumption that properties, commonly, are nothing more than simple field wrappers and that fields, commonly,
are only referenced in properties. And even if the latter was true, then the only way to get the data would be to reference the
property, but then you have to deal with all that "bounds checking", as you say, which can negatively affect performance or produce
undesireable changes in state. I prefer having more options.

I need the features I mentioned. I make fields internal and protected internal in some cases. I also mark them as NonSerializable
from time to time. Sometimes, fields are static.

The "special" case, as I see it, is coding without a need for flexibility.

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.

I think, techincally, it's a less complicated reason. Your idea is meant to help, but it actually hurts instead because it removes
flexibility and leaves something to be desired. And there's always something to be desired!

And just to clarify, I don't think that it's "not worth doing" because it might not be worth the effort. I think it won't add any
value at all.

I'm sure your intentions are good, however :)

[Dave Sexton]

Re: Properties

I guess that's constructive criticism...

--
Dave Sexton

"KH" <KH@discussions .microsoft.comw rote in message news:CF4A2319-0D77-49BA-BA07-442417573DDE@mi crosoft.com...

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

[Jon Slaughter]

Re: Properties


"KH" <KH@discussions .microsoft.comw rote in message
news:CF4A2319-0D77-49BA-BA07-442417573DDE@mi crosoft.com...

You haven't read this have you?
>

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

>
>

Sorry, I'm not here to win friends. I'm here to get a inteligent question
answered without all the bull. Sorry if that doesn't jive with what you
want. I just feel that I've asked a simpel question and I get condescending
remarks and ego trips that I tend to get in newsgroups like this. People
think that just because they sit in front of a computer screen all day long
then it makes them a genius and gives them the right to declare what is
right and wrong. I could simply ignore it but then what is the fun in that?

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

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

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

Excuse me... I didn't realize that democracy trumped truth.

[Jon Slaughter]

Re: Properties


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

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

Well, it seems odd that you would say it like that. Maybe I interpreted it
wrong and if I did then I'm sorry. If I didn't then I stand by what I said.
It seems your posts have been slightly condescending but again, it could be
misinterprettin g this. I tend to get that vibe any time I ask question in a
programming or engineering newgroup.

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

No, I'm just tired of people acting like they know it all. I'm not sure if
yoru that time of person but my impression is that you are. When someone
says something that effectively boils down to "I know it all and I say its
useless so it is"(which is effectively what you said or atleast two people
said(I'm having a hard time finding the comments) then am I suppose to get
from that? When you misunderstand me and then insist that what I'm talking
about is nonsense then what am I suppose to think?

I asked what is a very simple concept and I got a lot of hoopla about
nothing. Maybe its all my fault for not being clear. Thats fine. If its not
clear then don't answer are ask for clarity before assuming I have no idea
what I'm talking about. I might not be a genius but I'm not an idiot and I
don't appreciate it when the overtones suggest that. Now I know thinking
that I'm just exagerating but there have been several posts from others
where I get a completely different impression. Instead of saying things like
"You don't know what your talking about or you don't understand this or
that" they would say "I'm not sure I understand what you mean or maybe you
are thinking about it in the wrong way".

[Jon Skeet [C# MVP]]

Re: Properties

Jon Slaughter <Jon_Slaughter@ Hotmail.comwrot e:

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.

You now have extra fields for properties which don't need them.

Personally I *like* the fact that it's very clear when you've got a
field and when you've got a property. The only addition I'd like is for
trivial properties which are just straight get/set - it would be nice
to do that all in one line:

private string name public property Name;

which would be equivalent to:

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

That would save a lot more typing than your proposal, and is quite
explicit in the way that it's doing more than it does now - it doesn't
magically add anything without you specifically using a different
syntax.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Slaughter]

Re: Properties


"Jon Skeet [C# MVP]" <skeet@pobox.co mwrote in message
news:MPG.1f93fa d442964b3598d52 e@msnews.micros oft.com...

Jon Slaughter <Jon_Slaughter@ Hotmail.comwrot e:

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

>
You now have extra fields for properties which don't need them.
>

?

It will only create it if its there is a reference to it... and in any case
if they are not used by declared by the compiler implicitly they would be
optimized out.

Personally I *like* the fact that it's very clear when you've got a
field and when you've got a property. The only addition I'd like is for
trivial properties which are just straight get/set - it would be nice
to do that all in one line:
>

Yeah, but I think this is simply from how you were taught properties. If you
think of a property really a field in an of itself then its probably quite
easy. I posted the definition that msdn gives for a property and all
properties have to do with fields. Therefore a field exists somewhere either
explictly or implicitly. Right now we have to declare them explicitly. I
don't see it as a big leap to also include the ability to do it implicitly.
Although its possible to cause inital problems one can just use the old
methodology if they like and it won't cause any problems. I mean, its not
really any different than C# having an implicit destructor even if its not
declared. No one gets up and arms about that. I really don't see much of a
difference. Sometimes tradition is hard to break though.

How bout thinking about a property as a "container" ... sorta like a class.
It contains a field and accessors. Instead of declaring the field outside
the propertly like normal we declare it inside:

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

But now why even do this, as the return type should be the same. Ofcourse
maybe this is not the case in general but if its a general case then one
should just use the old method:

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

but most properties's fields are private which is the whole point. Obviously
they could be protected and hence one should use the old method of
explicitly declaring the field:

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


but now the name of the field is usually very similar if not identical to
the property(exclud ing case). Why not just use the name of the property
instead(and let the complier deal wiht the rest)?

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

Now this might be a little strange since we are using a self reference. I
think its ok as the compilier knows what to do(its not very hard to make it
understand).

But we could use the this keyword to make it clear.

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

either way works for me and it simplifies the "generic" property. For more
general properties one could ether extend this syntax or use the old method.

private string name public property Name;
>
which would be equivalent to:
>
private string name;
public string Name
{
get { return name; }
set { name = value; }
}
>
That would save a lot more typing than your proposal, and is quite
explicit in the way that it's doing more than it does now - it doesn't
magically add anything without you specifically using a different
syntax.

Its not equivilent unless you forgot to add the accessors in the first
place. Sure, one could do that but its almost identically syntactically the
same.

I did think about that but then one is essentially combining the two
syntaxes into one statement block. You might as well just keep the old
method so one doesn't break anything.


i.e., I'm not claming we break the accessor/property/field concept or syntax
in C#. I'm just saying that one could extend this for automatically deal
with simple properties. This takes the "work"(even though its not much) and
possible errors(even though its unlikely either... I'm thinking of
refactoring). i.e., it lets one write a simple generic property that is
commonly used. This is often done with other programming semantics too.

Its just an idea. I'm not saying its some revolutionary thing or that it
will improve the lifes of programmers. I'm just curious why it wasn't done.
Maybe it was stupidity or maybe there was another reason. Maybe the reason
is simply the same reason that you have. I do not know and that is why I
asked. I know it can be done and I know it would work but that is not the
point.

[Gino]

Re: Properties

What if you needed a private field that the class can change
but needs to be visible outside the class as readonly.

private string name
public readonly string Name
{
get {return name:}
}

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

[Chris Dunaway]

Re: Properties

Jon Slaughter wrote:

private double seconds;
>
public double Hours
{
get { return seconds / 3600; }
set { seconds = value * 3600; }
}

But what would your proposed parser do with this code. By the steps
that you listed, it would create a field called Hours (or whatever) and
in this case, it would be an unused field. To avoid that, your parser
would then have to examine the code in the property bodies and somehow
determine that it doesn't need the field after all. And what if the
get called a method? How would your parser determine how to create the
field then? Or would it not bother? It seems to me that your parser
would only be useful for the simplest case of a property and, at least
to me, seems like an awful amount of work for a small benefit.

[Jon Slaughter]

Re: Properties


"Chris Dunaway" <dunawayc@gmail .comwrote in message
news:1160416193 .921752.302690@ b28g2000cwb.goo glegroups.com.. .

Jon Slaughter wrote:

> private double seconds;
>>
> public double Hours
> {
> get { return seconds / 3600; }
> set { seconds = value * 3600; }
> }

>
But what would your proposed parser do with this code. By the steps
that you listed, it would create a field called Hours (or whatever) and
in this case, it would be an unused field. To avoid that, your parser
would then have to examine the code in the property bodies and somehow
determine that it doesn't need the field after all. And what if the
get called a method? How would your parser determine how to create the
field then? Or would it not bother? It seems to me that your parser
would only be useful for the simplest case of a property and, at least
to me, seems like an awful amount of work for a small benefit.
>

Since it is unused it would end up being optimized out. I woudln't have to
create to anything more complicated.

next...

[Jon Slaughter]

Re: Properties


"Gino" <someone@micros oft.comwrote in message
news:O$tACt36GH A.1256@TK2MSFTN GP04.phx.gbl...

What if you needed a private field that the class can change
but needs to be visible outside the class as readonly.
>
private string name
public readonly string Name
{
get {return name:}
}
>

I suppose either use that method or allow for the readonly keyword to mean
exactly what you have typed. Remember, I'm not breaking the only syntax so
one can declare anything they can in the original C#

[Jon Skeet [C# MVP]]

Re: Properties

Jon Slaughter <Jon_Slaughter@ Hotmail.comwrot e:

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.

You now have extra fields for properties which don't need them.

?
>
It will only create it if its there is a reference to it... and in any case
if they are not used by declared by the compiler implicitly they would be
optimized out.

Ah - that's extra to the logic you wrote before. Frankly I still don't
like it - creating a field only if it's referenced? It just feels
wrong.

Personally I *like* the fact that it's very clear when you've got a
field and when you've got a property. The only addition I'd like is for
trivial properties which are just straight get/set - it would be nice
to do that all in one line:

>
Yeah, but I think this is simply from how you were taught properties. If you
think of a property really a field in an of itself then its probably quite
easy.

But you shouldn't think of a property as a field, because it's not.

I posted the definition that msdn gives for a property and all
properties have to do with fields.

No they don't. Consider DateTime.Now, for example.

Therefore a field exists somewhere either
explictly or implicitly. Right now we have to declare them explicitly. I
don't see it as a big leap to also include the ability to do it implicitly.

It's hiding what's going on, which I don't think is a good idea.

Although its possible to cause inital problems one can just use the old
methodology if they like and it won't cause any problems. I mean, its not
really any different than C# having an implicit destructor even if its not
declared. No one gets up and arms about that. I really don't see much of a
difference. Sometimes tradition is hard to break though.

Don't misinterpret the protests against your idea as merely tradition.
I'm quite happy for things to change - but not in this way.

How bout thinking about a property as a "container" ... sorta like a class.
It contains a field and accessors. Instead of declaring the field outside
the propertly like normal we declare it inside:
>
public string Name
: private string name;
{
get { return name; }
set { name = value; }
}

Now *that* idea I've actually suggested before, in order to prevent
accidental use of fields within methods which should be using the
property.

But now why even do this, as the return type should be the same. Ofcourse
maybe this is not the case in general but if its a general case then one
should just use the old method:
>
public string Name
: private name;
{
get { return name; }
set { name = value; }
}
>
but most properties's fields are private which is the whole point. Obviously
they could be protected and hence one should use the old method of
explicitly declaring the field:
>
public string Name
: name;
{
get { return name; }
set { name = value; }
}
>
but now the name of the field is usually very similar if not identical to
the property(exclud ing case). Why not just use the name of the property
instead(and let the complier deal wiht the rest)?

Because I don't believe that implicitly generating fields is a good
idea, particularly when there's nothing making it clear that it's going
on. Creating a variable simply on the grounds that something tries to
refer to it is a bad idea IMO.

public string Name
{
get { return Name; }
set { Name = value; }
}
>
Now this might be a little strange since we are using a self reference. I
think its ok as the compilier knows what to do(its not very hard to make it
understand).

And what if you actually *want* to refer to the property? (It can
happen sometimes...)

But we could use the this keyword to make it clear.
>
public string Name
{
get { return Name.this; }
set { Name.this = value; }
}
>
either way works for me and it simplifies the "generic" property. For more
general properties one could ether extend this syntax or use the old method.

That would disambiguate, but I still don't like the idea of implicitly
adding fields.

private string name public property Name;

which would be equivalent to:

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

That would save a lot more typing than your proposal, and is quite
explicit in the way that it's doing more than it does now - it doesn't
magically add anything without you specifically using a different
syntax.

>
Its not equivilent unless you forgot to add the accessors in the first
place. Sure, one could do that but its almost identically syntactically the
same.

Um, the point is that it *would* be equivalent if C# supported that
syntax. I didn't forget to add the accessors in the first place - the
"property" contextual keyword would tell both the compiler and the
reader that property accessors should be added.

I did think about that but then one is essentially combining the two
syntaxes into one statement block. You might as well just keep the old
method so one doesn't break anything.

My suggestion wouldn't break anything either - and it would make it
more obvious what was going on.

i.e., I'm not claming we break the accessor/property/field concept or syntax
in C#. I'm just saying that one could extend this for automatically deal
with simple properties. This takes the "work"(even though its not much) and
possible errors(even though its unlikely either... I'm thinking of
refactoring). i.e., it lets one write a simple generic property that is
commonly used. This is often done with other programming semantics too.

And my suggestion would do that too, without the presence or absence of
a field having to be inferred from whether or not it was ever referred
to.

Its just an idea. I'm not saying its some revolutionary thing or that it
will improve the lifes of programmers. I'm just curious why it wasn't done.
Maybe it was stupidity or maybe there was another reason. Maybe the reason
is simply the same reason that you have. I do not know and that is why I
asked. I know it can be done and I know it would work but that is not the
point.

Well, I suspect that the language designers would have similar feelings
to the idea of implicit field creation that I do - whether or not a
variable exists shouldn't depend on whether or not something tries to
*use* it. Now, that's not to say that there shouldn't be a simpler way
of declaring properties - just that your suggested way is a bad one,
IMO.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Chris Dunaway]

Re: Properties

Jon Slaughter wrote:

next...

I'm not sure what you mean by this, my question was asked out of
curiosity. I don't know if your intent was simply to dismiss me or
not, I'll assume it wasn't.

In any case, you can post your idea to the feedback center for
inclusion into future versions.

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

[Rick Lones]

Re: Properties

Jon Slaughter wrote:

Sorry, I'm not here to win friends . . .

<remainder of whiny BS snipped>

Well, then as our Maximum Decider has said, "Mission Accomplished!" Frankly,
bud, you're not competent to fetch the coffee of most of the people who have
tried to seriously answer your question.

(BTW, statistics show that as many as 3 out of 10 surly undergraduate programmer
wannabes are not actually the hotshit computer scientists they think they are.
Could your friends be among them?)

You're right - this IS fun,
-rick-

[Arne Vajhøj]

Re: Properties

Jon Slaughter wrote:

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

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

Nonsense.

It is common to extend a langauge with new features.

It is very rare to remove existing features.

So that argument is bogus.

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

So you want to break existing C# code.

Not many chances MS will go that route.

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

I think I do.

You want to change the syntax of C# so that only code following
a certain coding convention remains valid C#.

Arne