Get Set property - access modifier

  • Thread starter Thread starter Eran.Yasso
  • Start date Start date
E

Eran.Yasso

Hi All,

this issue curious me for long time.
Any one knows why Microsoft didn't allow to different access modifier
for set and get?
To be more specific, why didn't they allow us to do it like this?

static string CSVFileName
{
public get { return _CSVFileName; }
private set { _CSVFileName = value; }
}

In this way I don't need to set different property or add function.


Thanks.
 
They do in 2.0; syntax is:

public static string CSVFileName {
get { return _CSVFileName; }
private set { _CSVFileName = value; }
}
Marc
 
this issue curious me for long time.
Any one knows why Microsoft didn't allow to different access modifier
for set and get?
To be more specific, why didn't they allow us to do it like this?

static string CSVFileName
{
public get { return _CSVFileName; }
private set { _CSVFileName = value; }

}

In this way I don't need to set different property or add function.

I don't know why they didn't put it in for .NET 1.1, but it's
available for .NET 2.0/C# 2.

You'd do:

public static string CSVFileName
{
get { return _CSVFileName; }
private set { _CSVFileName = value; }
}

And yes, I'm jolly glad it's now available :)
 
Hi All,

this issue curious me for long time.
Any one knows why Microsoft didn't allow to different access modifier
for set and get?
To be more specific, why didn't they allow us to do it like this?

static string CSVFileName
{
public get { return _CSVFileName; }
private set { _CSVFileName = value; }
}

In this way I don't need to set different property or add function.


Thanks.

You can, like this:

public string Foo {
get {
return m_Foo;
}
internal set {
m_Foo = value;
}
}
 
Because you don't need the private set{}? From anywhere where you could
call the private set{}, you can just do

_CSVFileName = value;


Peter
 
Ar u sure.. I am using .Net 2.0 and when I type this code it said me

Error 5 The name '_CSVFileName' does not exist in the current context
C:\Documents and Settings\cnirosh\My Documents\Visual Studio
2005\Projects\ACR.FileIndxer\FileIndexerManagement\FileIndex.cs 554 26
ACR.FileIndxer

Nirosh.
 
Oh! I missread this totaly.. sorry

Champika Nirosh said:
Ar u sure.. I am using .Net 2.0 and when I type this code it said me

Error 5 The name '_CSVFileName' does not exist in the current context
C:\Documents and Settings\cnirosh\My Documents\Visual Studio
2005\Projects\ACR.FileIndxer\FileIndexerManagement\FileIndex.cs 554 26
ACR.FileIndxer

Nirosh.
 
Hi Peter,

for that simple case, your right. But the set function could look more
complicated, or change, while the app evoolves. And then a set-method or
better a setter is usefull.

Christof
 
Yes. I take that point. I still think it's a bit weak, though. That
argument is fine for public setters, because the value is being set by
people who may not understand the domain of possible values for the
property. With a private set{}, the value is being set by the person who
determines that domain - i.e. the person coding the class itself.

Of course, there's no way of enforcing the use of a private set{}, either.
Is there? Or have I missed something?

BTW, I wouldn't want to start a war over this. I'm just curious as to the
justification.

:)


Peter
 
Yes. I take that point. I still think it's a bit weak, though. That
argument is fine for public setters, because the value is being set by
people who may not understand the domain of possible values for the
property. With a private set{}, the value is being set by the person who
determines that domain - i.e. the person coding the class itself.

Of course, there's no way of enforcing the use of a private set{}, either.
Is there? Or have I missed something?

BTW, I wouldn't want to start a war over this. I'm just curious as to the
justification.

:)

Peter







- Show quoted text -

thanks for the reply.
didn't know that. where can i see the changes when Microsoft releases
new new framework?
But you must admit that it looks odd that it exists only in .net
2.0 :)
 
Because you don't need the private set{}? From anywhere where you could
call the private set{}, you can just do

_CSVFileName = value;

That's only true if all your setter does is set the value. One nice thing
about properties is that they allow for other functionality (for example,
converting types, or marking something as "dirty" when a value has
changed, or updating a form when a value changes, or...I hope you get the
idea).

It seems to me that a private setter can be very useful in a variety of
situations.

Pete
 
Yes. I take that point. I still think it's a bit weak, though. That
argument is fine for public setters, because the value is being set by
people who may not understand the domain of possible values for the
property. With a private set{}, the value is being set by the person who
determines that domain - i.e. the person coding the class itself.

It sounds as though you are considering only error checking. I don't
think Christof meant to limit his comment to that scenario, and for sure
that's not the only reason a setter would have extra code in it. His
point about evolving code is good too. In addition to the examples I
offered in another post, it's also true that the way a private class
member is used could change over time, and restricting access to be
through a property would help allow that change to occur without having to
do a massive rewrite to the rest of the code.

(It doesn't get you out of having to at least visit and look at every use
of the member and related property -- double-checking is critical for
avoiding bugs -- but at least the goal would be that you only have to
*look*, and not write a bunch of new code everywhere that the member is
used).
Of course, there's no way of enforcing the use of a private set{},
either. Is there? Or have I missed something?

What do you mean "enforce"? It's true that even if the setter is set to
"private", there's nothing to stop code elsewhere in the class from still
accessing the underlying storage directly. But that would be a bug,
assuming the property was written for the purpose of encapsulating that
underlying storage. One hopes that anyone maintaining the code would be
aware of that and would use the property as intended.

Of course, there's no guarantees of that...perhaps that's a good argument
for inclusion of some way to restrict access of a class member to *only*
from within a property. For all the hand-holding that C# does, it's a
little surprising that they don't include something like that.

But none of that means that there's no reason to have a private setter.
BTW, I wouldn't want to start a war over this. I'm just curious as to
the justification.

Before I saw all this, I posted a different post in reply to your original
that I hope includes enough other examples of how a private setter is
useful. Please feel free to ask for clarification if you're still
wondering.

Pete
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top