Properties

[Jon Slaughter]

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

?

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.

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

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.

 

[Chris Dunaway]

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]

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-

 

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

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.

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

 

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

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

In most but not all cases.

But people who noone can understand can be divided
in 0.1% true geniuses and 99.9% fools.

Arne

 

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

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?

Nothin is preventing you from creating the new language
jon# with all the features you want.

But I would not switch to that language, because
I can not see any advantage of it.

And the preprocessor model has some disadvantages in
the build and debug process when it is not supported
by the compiler.

Arne

 

[Jon Slaughter]

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.

No, its just that you have given an example that does not say anything. You
asked how I would handle it and I said exactly how. If the "extension"
cannot handle it then one just uses the old more general version.

What ever you can do in C# now you could do with my extensions. They are not
replacing anything or changing anything but adding to it.