Attributes: I want my setter to be protected or private

[Flipje]

In my view, there is a major drawback to using attributes: the getter and
the setter have identical protection levels. But I usually want the getter
to be public and the setter to be protected or even private.

Example: I would have liked this to be possible:

int Thingy
{
public get { return mThingy; }
private set { mThingy = value; }
}

Unfortunately, it isn't. So now, instead of attributes, I use good old
GetThingy () and SetThingy () functions. I've been trying to find a decent
discussion about the subject, but it seems like I'm the only one who sees
having identical protection levels as a problem. So, am I missing something?
Is there some way to make attributes work the way I want?

 

[Mattias Sjögren]

So, am I missing something?

Is there some way to make attributes work the way I want?

It's possible in C# 2 but not earlier versions.

And FYI, what you call attributes are usually called properties, since
(custom) attributes is something else in .NET.


Mattias

 

[Richard Grimes]

In my view, there is a major drawback to using attributes: the getter
and the setter have identical protection levels. But I usually want
the getter to be public and the setter to be protected or even
private.

It has always been possible in managed C++, the problem is C#
properties, its not a .NET problem. BTW it is fixed in C# 2.0.

Example: I would have liked this to be possible:

int Thingy
{
public get { return mThingy; }
private set { mThingy = value; }
}

Unfortunately, it isn't. So now, instead of attributes, I use good old
GetThingy () and SetThingy () functions. I've been trying to find a

Well, properties are just syntactic sugar.

obj.Thingy = 42;
obj.set_Thingy(42);

are just the same (although C# prevents you doing the latter, but they
are still the same).

If the setter is protected or private then it means that only the class,
or derived classes have access. In this case why not implement a
SetThingy method? You do not have the syntactic sugar, but is that a big
problem? If you do this you can still have a public property called
Thingy that has only the getter, so your users get the syntactic sugar.

decent discussion about the subject, but it seems like I'm the only
one who sees having identical protection levels as a problem. So, am
I missing something? Is there some way to make attributes work the
way I want?

Oh, there are far worse problems with properties. For example, look at
this:

Size size;
public Size MySize
{
get{return size;}
set{size = value;}
}

obj.MySize.Height = 200;

What's wrong? Well Size is a value type so you get a new value type
returned from obj.get_MySize, if you change the Height property then you
change it on the *copy* and so it does not affect the size field. The C#
compiler disallows this, but it is not immediately obvious what is
wrong. This code is clear:

obj.SetSize(new Size(200, 200));

A far worse problem is that getters and setters usually do more than
just access the field. Typically they generate events. What's wrong with
the following?

Form f = new Form();
f.Visible = true;
// assume that we first want the form to show the default size and
position
f.Width = 200;
f.Height = 200;
f.Left = 100;
f.Top = 100;

The problem is that each of these properties generates events in their
setter. The reason is that each one calls the SetBounds method that
generates the events. So you get *four* events when you really intend to
just get one. In this case it is *far* better to call SetBounds instead
of using the properties.

As I said, properties are just syntactic sugar, and coding (like tea)
does not need sugar.

Richard

 

[Jon Skeet [C# MVP]]

As I said, properties are just syntactic sugar, and coding (like tea)
does not need sugar.

It's a lot nicer with it though. Are you really saying that you'd
prefer it if we *didn't* have syntactic sugar? Would you prefer to
write try/finally all over the place rather than the "using" statement?
Would you rather we didn't have foreach?

Syntactic sugar is particularly important IMO in the situations where
it makes doing the *right* thing the *easy* thing to do as well - such
as with the using statement.

 

[Richard Grimes]

It's a lot nicer with it though. Are you really saying that you'd
prefer it if we *didn't* have syntactic sugar? Would you prefer to

No. I have been doing a lot of unmanaged C++ recently and it seemed to
be rather ugly for me to use a method call to provide the equivalent of
a read only property, but that ugliness was only apparent because
previously I've done lots of C# programming. Of course, they are the
same.

Properties *are* syntactic sugar, and if there was a need to chuck out
unnecessary features in .NET properties would be first on my list. The
example I gave with SetBounds should be enough to convince you of that.
The unnecessary calling of SetBounds multiple times because the coder
decider decided to set Width, Height, Left and Top individually is a
waste of CPU cycles and means that events are called unnecessarily.

write try/finally all over the place rather than the "using"
statement?

using does not save many keystrokes (and yes, in managed C++ I had to
code it myself with try/__finally). It makes the code more readable,
which is good, and unlike properties I cannot see a downside to using,
erm, using.

Would you rather we didn't have foreach?

Again, I am used to calling GetEnumerator, MoveNext and get_Current in
managed C++. And again, foreach makes the code more readable. I don't
see any downside in using foreach.

Syntactic sugar is particularly important IMO in the situations where
it makes doing the *right* thing the *easy* thing to do as well - such
as with the using statement.

Right. But properties have a little bit of sorbitol to provide some of
the sweetness in the syntactic sugar, and we all know what an excess of
sorbital can do for you ;-)

Richard

 

[Jon Skeet [C# MVP]]

No. I have been doing a lot of unmanaged C++ recently and it seemed to
be rather ugly for me to use a method call to provide the equivalent of
a read only property, but that ugliness was only apparent because
previously I've done lots of C# programming. Of course, they are the
same.

Indeed - but ugly is ugly.

Properties *are* syntactic sugar, and if there was a need to chuck out
unnecessary features in .NET properties would be first on my list. The
example I gave with SetBounds should be enough to convince you of that.

Not really - they just show that properties can be used ineffectively.
If you didn't have actual properties, there'd probably just be
SetWidth, SetHeight, SetTop and SetBottom methods. What would have been
gained?

The unnecessary calling of SetBounds multiple times because the coder
decider decided to set Width, Height, Left and Top individually is a
waste of CPU cycles and means that events are called unnecessarily.

I don't see how that's the fault of properties rather than the fault of
the person using them.

using does not save many keystrokes (and yes, in managed C++ I had to
code it myself with try/__finally). It makes the code more readable,
which is good, and unlike properties I cannot see a downside to using,
erm, using.

using saves a fair few keystrokes if you've got a resource which may or
may not actually be acquired (i.e. may be null), but it's not the
keystrokes which are important - it's getting it right. using makes it
easy to do the right thing, and gains readability at the same time.

Again, I am used to calling GetEnumerator, MoveNext and get_Current in
managed C++. And again, foreach makes the code more readable. I don't
see any downside in using foreach.
Likewise.


Right. But properties have a little bit of sorbitol to provide some of
the sweetness in the syntactic sugar, and we all know what an excess of
sorbital can do for you ;-)

Can properties be abused? Absolutely. However, they vastly increase
readability IMO, having written quite a bit of Java recently. I'd
*much* rather see:

foo.Bar = something.First.Second;

than

foo.setBar (something.getFirst().getSecond());