473,325 Members | 2,342 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

Attributes: I want my setter to be protected or private

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?


Oct 31 '05 #1
5 1631
>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

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Oct 31 '05 #2
Flipje wrote:
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
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Nov 1 '05 #3
Richard Grimes <ri******@mvps.org> wrote:

<snip>
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 1 '05 #4
Jon Skeet [C# MVP] wrote:
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


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
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Nov 4 '05 #5
Richard Grimes <ri******@mvps.org> wrote:
Jon Skeet [C# MVP] wrote:
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


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


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


Likewise.
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 ;-)


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());

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 10 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: KN | last post by:
I've run into such problem: I have something like this: class A(object): def __init__(self): self.__value = None class B(A): def test(self):
1
by: Bruce | last post by:
I use btnSave.Attributes.Add("onclick", "ShowMessage()") to link my web control button to a JavaScript function. It works well until I added a Validation control into the page. After that,...
5
by: Flipje | last post by:
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...
3
by: vivekian | last post by:
Hi , I am moving on from C++ to C# . Though have understood how attributes work , still dont understand what need do the fullfil ? Where should they be used ? What are their advantages ? some...
12
by: Adam Sandler | last post by:
Hi all, I hope this is an easy one... Using VWD 2005. When I call my accessor method (getName) I always receive an empty string back. Debugging shows there should be something there but I...
1
by: LG | last post by:
I want to add attributes to a custom dropdownlist and I found some code on Internet that doesn't work after post back. First time the control has the attributes, but after postback the attributes...
5
by: Kimmo Laine | last post by:
Hi is there a way to change propertys attribute from the code? Let´s say that i have the following property in my class: public int Count } Is there a way to change the displayname, from...
3
by: Martin Pöpping | last post by:
Hello, I´m coming from the Java World. Here Programmers often use (like in C++?) getter and setter methods. F.e.: class Mirror{ private int width_;
3
by: Beorne | last post by:
In the classes I develop my attributes are always private and are exposed using properties. directly or to access the attributes using the properties? Does "wrapper" setter/getter properties...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.