Possibility of readonly properties

[Harlan Messinger]

To make autoproperties even more flexible, I'm wondering about the
prospect of readonly functionality being made available. Are there
reasons why it would be unwise, impractical, or harmful to allow

public readonly MyProperty { get; private set; }

or

public MyProperty { get; private readonly set; }

meaning that the setter can only be called from inside a constructor?

 

[Gregory A. Beamer]

To make autoproperties even more flexible, I'm wondering about the
prospect of readonly functionality being made available. Are there
reasons why it would be unwise, impractical, or harmful to allow

public readonly MyProperty { get; private set; }

or

public MyProperty { get; private readonly set; }

meaning that the setter can only be called from inside a constructor?

I don't see why it could not be done, but I am not sure what this buys
developers. I tis functionally equivalent to:

public readonly string MyProperty;

In addition, there is not much it buys you in safety. Sure someone could
create reflection scaffolding to poke at a class, but why would he do
it? if someone is hell bent on playing this game, they can rip it
anyway.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Peter Duniho]

To make autoproperties even more flexible, I'm wondering about the
prospect of readonly functionality being made available. Are there
reasons why it would be unwise, impractical, or harmful to allow

public readonly MyProperty { get; private set; }

or

public MyProperty { get; private readonly set; }

meaning that the setter can only be called from inside a constructor?

The main issue is, as Patrice says, the question of balancing need with
cost.

Every language change comes with a cost, sometimes a fairly large one
(even for what appears to be a simple change). Automatic properties are
a convenience, not necessary for writing full-featured C# programs, and
the more complicated they get, the worse the cost:benefit ratio gets.

Now, that said, I think it's possible that this specific feature -- some
form of read-only behavior on automatic properties -- may actually
appear some time. There's no fundamental reason it wouldn't work, and
there's enough of a benefit to read-only semantics that it could be
viewed as beneficial enough to justify _some_ degree of complication to
the automatic property syntax.

One should not expect a large change. The more variation in behavior
that's possible with an automatic property, the more likely it is that
the C# programmer should just be using a non-automatic property.

On a related note: one suggestion I've seen is to allow a property to
have its own members, so that implementation details for the property
are fully encapsulated. This doesn't address the automatic property
issue, but it turns out that at least some people who are asking for
better read-only support in automatic properties, they are _really_
looking for a way to continue to take advantage of the implicit
encapsulation hiding of automatic properties (i.e. the fact that the
backing field is inaccessible to any other code), but to at the same
time have a specific read-only behavior.

Providing that encapsulation via other means than automatic properties
(after all, again...automatic properties are really just a convenience,
rather than being intended as a way to provide additional OOP
functionality) could be viewed as more worthwhile than meddling with the
automatic property design, especially since it would provide real
benefits to a broader range of C# users.

All that said, this kind of stuff is all up to the C# language design
team. They have a much better "big picture" view, and while probably a
feature along these lines is probably something they'd consider, I'm
sure they also have a long list of other stuff they'd also like to
include. At the same time, there's value in the language evolving
slowly and carefully. So any one "pet feature" one might want has a
relatively low chance of being included, even if it's something that
would be really useful.

Pete

 

[Harlan Messinger]

I don't see why it could not be done, but I am not sure what this buys
developers. I tis functionally equivalent to:

public readonly string MyProperty;

I suppose that's true, except for the part about preferring to separate
the implementation from the interface and not wanting to restrict
oneself to implementing the public interface MyProperty with a single
field by that name.

In addition, there is not much it buys you in safety. Sure someone could
create reflection scaffolding to poke at a class, but why would he do
it? if someone is hell bent on playing this game, they can rip it
anyway.

I see it as protection from myself when creating methods in the class,
basically as a way to help the compiler keep me from making mistakes by
assigning to one thing something I was supposed to assign to another
thing, etc. I don't think it's tremendously important, all things
considered, but just now I thought it would be a good idea to make a
couple of properties in a class I created readonly for the same reasons
one might make a field readonly, and then realized I wasn't sure that it
could be done, and then confirmed that it couldn't.

 

[Gregory A. Beamer]

I suppose that's true, except for the part about preferring to
separate the implementation from the interface and not wanting to
restrict oneself to implementing the public interface MyProperty with
a single field by that name.

What part of the following separates interface from implementation?

private string MyProperty { get; private readonly set; }

Unless you are creating the properties in interface, there is little.
And, if you are creating state items as part of an interface, the
private set does almost everything, except stopping you from privately
setting in routines other than the constructor. The question, overall,
is what do you want MS working on to improve C#. Or, is this change (a
fringe case, IMO) worth dropping other compiler features?

I see it as protection from myself when creating methods in the class,
basically as a way to help the compiler keep me from making mistakes
by assigning to one thing something I was supposed to assign to
another thing, etc. I don't think it's tremendously important, all
things considered, but just now I thought it would be a good idea to
make a couple of properties in a class I created readonly for the same
reasons one might make a field readonly, and then realized I wasn't
sure that it could be done, and then confirmed that it couldn't.

A private set offers you most of the protection you have asked for. If
you truly need readonly, then the following:

public readonly string MyProperty;

offers the same.

I am not against your idea, as it is simply a syntax change. I just
don't see that alteration of the compiler to work with private readonly
setters as a worthwhile exercise if matched up against contravariance
and covariance (just one example). I am less enthralled that I can
syntactically handle the constructor only scenario with the construct I
have shown.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Peter Duniho]

What part of the following separates interface from implementation?

private string MyProperty { get; private readonly set; }

Unless you are creating the properties in interface, there is little.

Surely you did not intend to change the "public" for the property to
"private".

Assuming the property is actually public, the above does separate
interface from implementation. Just because one didn't write the
implementation, that doesn't mean it's not there, nor that it's not
separate from the interface.

[...]
A private set offers you most of the protection you have asked for. If
you truly need readonly, then the following:

public readonly string MyProperty;

offers the same.

Note Harlan's previous comment: "and not wanting to restrict oneself to
implementing the public interface MyProperty with a single field by that
name". Specifically, if you code the "property" as a field, it's much
more difficult to modify the implementation in the future.

That's exactly why properties are so useful. They expose an interface,
not an implementation. By always using properties to start with, the
class is not locked into a particular implementation, and the
implementation can change in the future without modification to client code.

A field doesn't give you that.

As I've mentioned elsewhere in this thread, I agree that the win for
such a change probably isn't justified by the cost. If we're to see the
overall issues addressed, they probably should be addressed in a more
comprehensive way (more work for the language team, but more payback
too). But Harlan's goals are certainly quite reasonable, and not
satisfied at all by simply exposing a field instead of using a property.

Pete

 

[Gregory A. Beamer]

As I've mentioned elsewhere in this thread, I agree that the win for
such a change probably isn't justified by the cost. If we're to see
the overall issues addressed, they probably should be addressed in a
more comprehensive way (more work for the language team, but more
payback too). But Harlan's goals are certainly quite reasonable, and
not satisfied at all by simply exposing a field instead of using a
property.

I stated he could not achieve all of his goals. The field solves the "I
need it to load in the constructor only" problem, which is the only
reason I mentioned it. I was not debating it was the proper method of
solving the problem.

If you want to break it down, you can solve the problem in this manner:

private readonly string _myProperty;

public string MyProperty
{
get;
}

Also not optimal, as you do not have the constructor problem solved on
the actual property. Plus you are adding additional typing to get 'er
done.

Note that I am not arguing that Harlan's goals are unreasonable. My main
point, however, was summed up as:

"I am not against your idea, as it is simply a syntax change. I just
don't see that alteration of the compiler to work with private readonly
setters as a worthwhile exercise if matched up against contravariance
and covariance (just one example)."

In essence, is this particular feature compelling enough to postpone
other features? I would say not.

I think you are drawing too much into my post. ;-)

Peace and Grace,


--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************