Calling protected members

[TT (Tom Tempelaere)]

Hi there

The line marked *** doesn't compile. I wonder why the designers of C# decided to disallow this. Rationale?
Are there plans to change this? This feature forces me to make things public when the operations are in fact protected. This breaks a lot of patterns for me

public class C
public void F( C other)
this.G()
other.G(); // **

protected void G(
{
Thanks you
Tom.

[Jon Skeet [C# MVP]]

TT (Tom Tempelaere) <"=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?=" <_N_
0SPA|/\|t*******@hotmail.com|/\|APS0_N_>> wrote:

The line marked *** doesn't compile.

Yes it does. At least, it does for me. Could you give a short but
complete example which *doesn't* compile. This is what I tried and
managed to compile:

public class C {
public void F( C other) {
this.G();
other.G(); // ***
}
protected void G()
{}
}

// Just to avoid having to compile it to a library
class Test
{
static void Main()
{
}
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[TT (Tom Tempelaere)]

Hi Jon

I tried to strip my problem in a minimal way, and I guess it was just too minimal. The problem is more complex. Second try

public class Base
protected abstract void DoStuff()
public class Derived_1 : Base
protected override void DoStuff() {
public class Derived_2 : Base
private Derived_1[] pool

protected override void DoStuff()
foreach( Base base in pool
base.DoStuff(); // **

The error message when compiling is
<error_message
"C:\Blabla\Derived_2.cs(94): Cannot access protected member Base.DoStuff()' via a qualifier of type 'Base'; the qualifier must be of type 'Derived_2' (or derived from it)
</error_message

The problem arises in my thread pool class. A thread pool (Derived_2) manages several threads (Derived_1), and is a thread itself (Base). The thread pool thread dispatches tasks to idle pool threads. In my project I cannot make DoStuff public, because it is implementation functionality, not public functionality

This makes a lot of patterns impossible to implement elegantly. It forces me to make DoStuff public, whereas the operation is really protected. Internal would work only within the same namespace, and that isn't sufficient in my case (extensible library)

What do you think
PS: I know that there is already a thread pool class in C#. I just wanted my own

Thanks
Tom

----- Jon Skeet [C# MVP] wrote: ----

TT (Tom Tempelaere) <"=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?=" <_N
0SPA|/\|t*******@hotmail.com|/\|APS0_N_>> wrote

The line marked *** doesn't compile.

Yes it does. At least, it does for me. Could you give a short but
complete example which *doesn't* compile. This is what I tried and
managed to compile

public class C
public void F( C other)
this.G()
other.G(); // **

protected void G(
{
// Just to avoid having to compile it to a librar
class Tes

static void Main(


--
Jon Skeet - <sk***@pobox.com
http://www.pobox.com/~skee
If replying to the group, please do not mail me to

[TT (Tom Tempelaere)]

Jon

Actually I think it is logical behaviour. But I don't see a good way of working around it, except making the DoStuff method internal and place the thread class, thread pool class and task executer class in the same namespace

Tom.

[Jochen Kalmbach]

=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?= wrote:

public class Base {
protected abstract void DoStuff();
}

public class Derived_2 : Base {
protected override void DoStuff() {
foreach( Base base in pool )
base.DoStuff(); // ***
}
}

You cannot call an abstract method!

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp
Do you need daily reports from your server ?
http://sourceforge.net/projects/srvreport/

[Jon Skeet [C# MVP]]

TT (Tom Tempelaere) <"=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?=" <_N_
0SPA|/\|t*******@hotmail.com|/\|APS0_N_>> wrote:

I tried to strip my problem in a minimal way, and I guess it was just
too minimal. The problem is more complex. Second try:
<snip>
The error message when compiling is:
<error_message>
"C:\Blabla\Derived_2.cs(94): Cannot access protected member
Base.DoStuff()' via a qualifier of type 'Base'; the qualifier must be
of type 'Derived_2' (or derived from it)"
</error_message>
Right. Basically, you can call protected methods which have been
declared by a parent on *this* (or another instance of the same class),
and you can call protected methods which have been declared by a
descendant of your current class, but you can't call protected methods
declared by a parent on an instance of a different class.

This is (I believe) to stop you from calling protected methods
"across" the inheritance hierarchy, when they're designed to be called
*within* the inheritance hierarchy (up or down).

See http://www.jaggersoft.com/csharp_standard/10.5.3.htm for more
information.
The problem arises in my thread pool class. A thread pool (Derived_2)
manages several threads (Derived_1), and is a thread itself (Base).
The thread pool thread dispatches tasks to idle pool threads. In my
project I cannot make DoStuff public, because it is implementation
functionality, not public functionality.

This makes a lot of patterns impossible to implement elegantly. It
forces me to make DoStuff public, whereas the operation is really
protected. Internal would work only within the same namespace, and
that isn't sufficient in my case (extensible library).

Namespaces have nothing to do with accessibility - internal would work
within the same *assembly*.

I had a bit of trouble following your example, to be honest, but I
think you're really trying to bend protected access to do something
it's not designed for in .NET.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[TT (Tom Tempelaere)]

Jochen

That is not true. I can always call a method declared abstract on a reference variable. I just can't create an object from an abstract class. Two different issues

Base b = new Base(); // impossible, abstract clas

Base d = new Derived_1(); // no probs, Derived_1 not abstrac
d.DoStuff(); // no prob

This is equivalent in the foreach loop of my example, the Derived_1 references are cast to Base references

Tom

----- Jochen Kalmbach wrote: ----

=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?= wrote

public class Base
protected abstract void DoStuff()

public class Derived_2 : Base

protected override void DoStuff()
foreach( Base base in pool
base.DoStuff(); // **

You cannot call an abstract method

--
Greeting
Joche

Do you need a memory-leak finder
http://www.codeproject.com/tools/leakfinder.as
Do you need daily reports from your server
http://sourceforge.net/projects/srvreport

[TT (Tom Tempelaere)]

Jon

----- Jon Skeet [C# MVP] wrote: ----

TT (Tom Tempelaere) <"=?Utf-8?B?VFQgKFRvbSBUZW1wZWxhZXJlKQ==?=" <_N
0SPA|/\|t*******@hotmail.com|/\|APS0_N_>> wrote
[...]

The error message when compiling is
<error_message>> "C:\Blabla\Derived_2.cs(94): Cannot access protected membe
Base.DoStuff()' via a qualifier of type 'Base'; the qualifier must b
of type 'Derived_2' (or derived from it)
</error_message
Right. Basically, you can call protected methods which have been
declared by a parent on *this* (or another instance of the same class),
and you can call protected methods which have been declared by a
descendant of your current class, but you can't call protected methods
declared by a parent on an instance of a different class

This is (I believe) to stop you from calling protected methods
"across" the inheritance hierarchy, when they're designed to be called
*within* the inheritance hierarchy (up or down)

See http://www.jaggersoft.com/csharp_standard/10.5.3.htm for more
information

I see. It is actually very logical..

[... This makes a lot of patterns impossible to implement elegantly. I
forces me to make DoStuff public, whereas the operation is reall
protected. Internal would work only within the same namespace, an
that isn't sufficient in my case (extensible library)

Namespaces have nothing to do with accessibility - internal would work
within the same *assembly*

Thanks for the correction

I had a bit of trouble following your example, to be honest, but I
think you're really trying to bend protected access to do something
it's not designed for in .NET
--
Jon Skeet - <sk***@pobox.com>

Indeed. I will have to either use internal, or make public helpers, or redesign ;-

Thanks
Tom