Property - Public Get but Private Set

  • Thread starter Thread starter Michael Moreno
  • Start date Start date
M

Michael Moreno

Hello,

I would like to have a property where the Get is public but the Set is
private.
How do I do this with only one property?

thanks.
 
Michael Moreno said:
I would like to have a property where the Get is public but the Set is
private.
How do I do this with only one property?

Unfortunately you can't yet - but you will be able to with the next
version of C#.
 
You can do this sort of. Just make the variable private, and only provide a
get method for the property.
Of course if you wanted to have inherent code run every time the var is set
you would need to create another property.

ie.

private string myVar;

public string MyVar {
get{ return myVar; }
}

public void DoStuff() {
myVar = "woop";
}


Lee.
 
I would like to have a property where the Get is public but the Set is
Unfortunately you can't yet - but you will be able to with the next
version of C#.


I feel that properties with differenct access for get and set will things
more complicated.
Additionally It is illogical. Either I have access to that property or not.
Also if you want to physically separate member in your sourcecode by their
access level this is stupid.
 
codymanix said:
I feel that properties with differenct access for get and set will things
more complicated.

I don't really think so.
Additionally It is illogical. Either I have access to that property or not.
Also if you want to physically separate member in your sourcecode by their
access level this is stupid.

Not at all. It's perfectly logical, and it exists all over the place -
just not in .NET, currently.

It makes perfect sense for the internals of a class to be able to set
something in a controlled manner (i.e. using a property), but the
property can only be *read* from the outside. (Count in ArrayList is a
good example of this.)

Currently we're forced to have a readonly property and a separate
setter method when we want to do anything nice like value checking,
event notification etc. That's ludicrous.

I've wanted this ever since I've started learning C#...
 
Not at all. It's perfectly logical, and it exists all over the place -
just not in .NET, currently.

It makes perfect sense for the internals of a class to be able to set
something in a controlled manner (i.e. using a property), but the
property can only be *read* from the outside. (Count in ArrayList is a
good example of this.)

count is a private variable in ArrayList whereas Count is a public property.
so What is the problem?
Currently we're forced to have a readonly property and a separate
setter method when we want to do anything nice like value checking,
event notification etc. That's ludicrous.

A getter and setter of a property imho always belongs together. As I said
you cannot separate public and private members if they belong to the same
property. A sourcefile should separarate the code public and private into
separate sections which is not possible with a private setter and a public
getter. The c# language designers had their reasons why they made them
together.

But sure, it would certainly have its advantages. We will see what the next
version of C# will bring to us.
 
codymanix said:
count is a private variable in ArrayList whereas Count is a public property.
so What is the problem?

So the author of ArrayList may well want to be able to set Count as a
property, rather than as a direct variable access - whether for bounds
checking purposes or whatever. Currently, you can't do that unless
Count is publicly settable as well.
A getter and setter of a property imho always belongs together. As I said
you cannot separate public and private members if they belong to the same
property.

You can't, but that's the problem.
A sourcefile should separarate the code public and private into
separate sections

According to you, maybe - not everyone works like that though. I know I
don't. I don't really see that it adds much value, to be honest.

Personally I organise my source by type of operation - so I might have
a public method which calls some private methods for implementation,
and I would group those together, possibly in a region.
which is not possible with a private setter and a public
getter.
The c# language designers had their reasons why they made them
together.

For general clarity, yes. When they had to have the same access
modifier, that didn't upset your "organise source by access" way of
doing things - but now it will. I don't believe the C# language
designers' reasons were for your code organisation scheme though.
But sure, it would certainly have its advantages. We will see what the next
version of C# will bring to us.

Indeed. Maybe it won't affect you, but it'll certainly affect me. I
like to avoid setting variables directly anywhere other than in
properties - and basically I can't do that at the moment :(
 
Back
Top