Jon Skeet said:
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(excluding 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.
This is a simple concept that I would bet makes complete