I need something between protected and public

[not_a_commie]

It seems I need one more type of member protection in my C# classes. I
run into this regularly. I've got a class X in assembly A. Class Y in
assembly B inherits from X and has a constructor that takes an
instance of X. The only way class Y can access data on the instance of
X coming into its constructor is if I make it public on X. Public is
too strong in this situation if data is only used in constructors of
derived classes. I want the ability to allow privileged access to
members of an instance from derived classes. (Protected allows this
privileged access only on the base instance.) Has anyone else run into
this shortcoming?

 

[Jon Skeet [C# MVP]]

It seems I need one more type of member protection in my C# classes. I
run into this regularly. I've got a class X in assembly A. Class Y in
assembly B inherits from X and has a constructor that takes an
instance of X. The only way class Y can access data on the instance of
X coming into its constructor is if I make it public on X. Public is
too strong in this situation if data is only used in constructors of
derived classes. I want the ability to allow privileged access to
members of an instance from derived classes. (Protected allows this
privileged access only on the base instance.) Has anyone else run into
this shortcoming?

Sorry, it's not clear to me what protected doesn't do for you. Could
you give a concrete example with code?

 

[Chris Mullins [MVP - C#]]

It's not qutie what you described, but it'll probably do the trick:

1 - Mark your method as internal
2 - Grant explicit privlidges to other assemblies to see your Internal
methods.

[assembly:
InternalsVisibleTo("Coversant.SoapBox.Services.SomeService,PublicKey=....")]

.... although, I must admit, I'm not clear on why "protected" isn't working
for you.

 

[Guest]

As Jon alluded to, I'm not sure whether what you describe is a shortcoming or
simply an attempt to make the language's access modifiers do something that
would normally be done in another way. If,as you opine, you "run into this
regularly", it could be more of a developer design paradigm limitation rather
than a framework shortcoming. More details would certainly help.

--Peter
"Inside every large program, there is a small program trying to get out."
http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://www.blogmetafinder.com

 

[Peter Duniho]

Sorry, it's not clear to me what protected doesn't do for you. Could
you give a concrete example with code?

I suspect he's trying to do something like this:

class X
{
protected int _value;

public X(int value)
{
_value = value;
}
}

class Y : X
{
public Y(X x)
{
// This line generates CS1540 because
// x._value is not a legal expression here
_value = x._value;
}
}

or maybe this:

class Y : X
{
// same problem with x._value
public Y(X x) : base(x._value) { }
}

Why C# doesn't allow this, I'm not completely clear on. But it
doesn't. Code in class Y can only access the protected member on an
instance of Y, not X.

Pete

 

[Jon Skeet [C# MVP]]

Why C# doesn't allow this, I'm not completely clear on. But it
doesn't. Code in class Y can only access the protected member on an
instance of Y, not X.

Ah, right. I think the idea is to give you more information about types
of your own instance, without exposing the details of "foreigners". I
suspect it's not so much a C# decision as a CLR design decision.

Can't say I've ever had a problem with it though...

 

[Christof Nordiek]

On 2007-11-21 13:58:59 -0800, Jon Skeet [C# MVP] <[email protected]> said:

I suspect he's trying to do something like this:

class X
{
protected int _value;

public X(int value)
{
_value = value;
}
}

class Y : X
{
public Y(X x)
{
// This line generates CS1540 because
// x._value is not a legal expression here
_value = x._value;
}
}

OK, here an idea of a solution:

class X
{
//This is accessible by a derived class only, if the accessed expression
is of that derived class.
protected int _value;

//This is accessible by derived class.
protected static GetValue(X x)
{
return x._value;
}

public X(int value)
{
_value = value;
}
}

class Y: X
{
public Y(X x)
{
_value = GetValue(x);
}
}

Christof

 

[not_a_commie]

The two solutions proposed (protected static and privileged internal
access) are both excellent suggestions that will help me solve this
problem. Thank you.

 

[Peter Duniho]

The two solutions proposed (protected static and privileged internal
access) are both excellent suggestions that will help me solve this
problem. Thank you.

For what it's worth, my preferred solution (assuming that all of the
interesting criteria were already included in your original post) would
be simply to define a constructor for X that takes an instance of X and
use the protected field there instead of in Y.

Especially if you are considering creating a static getter method in
class X anyway (i.e. you're going to tie the API for X to the needs of
Y), you might as well do it in a more general-purpose, usable way.

This of course assumes that the use of the protected field is for
something reasonably obvious. You weren't specific about how you'd use
it, but if you need to get the value for something you're going to do
to Y, but don't intend to ever do anything to the actual protected
member of X in the new instance then this suggestion wouldn't work.

Whether that's the case, I don't know. Your original post wasn't specific.

Also worth maybe nothing, but if for some reason defining a constructor
for X that takes an instance of X doesn't work, then I'd suggest that
there's a possibility your overall design isn't as clean as it could or
ought to be. I have found that in almost all situations, if I find
myself trying to write code to get around an apparent language
limitation, it's usually because I'm being hard-headed and not paying
attention to the strong hints the language is giving me to fix my
design.

Pete