Is this a D puzzler or a bug?

janderson askme at me.com
Sun Apr 1 03:01:17 PDT 2007


Chris Nicholson-Sauls wrote:
> Jarrett Billingsley wrote:
>> "Bradley Smith" <digitalmars-com at baysmith.com> wrote in message 
>> news:eujsku$2njp$1 at digitalmars.com...
>>> What is wrong with the following code?
>>>
>>> class A {
>>>   protected void method() {}
>>> }
>>>
>>> class B : public A {
>>>   protected void method() {
>>>     A.method();
>>>   }
>>> }
>>>
>>> Answer:
>>>
>>> If A and B are defined in the same module, A is able to access the 
>>> non-static protected method of its superclass using a static method 
>>> call.
>>>
>>> However, if A and B are defined in different modules, the error 
>>> "class a.A member method is not accessible" occurs.
>>>
>>> Is this a bug? (I don't know. I am really asking.)
>>>
>>
>> This is "the way C++ does it" and therefore the way D should do it as 
>> well. It also means that B can't access any protected members of A 
>> references. Stupid, I know, and it's never going to change as long as 
>> Walter is in charge.
>>
>>> Current solution:
>>>
>>> Replacing "A.method()" with "super.method()" corrects the problem.
>>
>> That's really how you're "supposed" to do it.  It's also a little 
>> nicer-looking, since it's obvious you're calling the base class's 
>> implementation of the method.
>>
> 
> In trying to figure out an idea to put forward on how me might be able 
> to call super-class definitions directly (since the problem I see with 
> super.method() is that you can't selectively invoke a specific ancestor, 
> only your direct parent) I had the sudden cute thought about how it can 
> be done in MiniD (untested).  (Granted MiniD doesn't have 
> protection/visibility attributes, plus both inheritance and 
> instantiation behave differently from D, so its moot in that context, 
> but the idea stands conceptually.)
> 
> class A {
>   function method () {}
> }
> 
> class B : A {
>   function method () {
>     method(with this as A); // Its cute how existing syntax can read 
> sometimes.
>   }
> }
> 
> 
> Thinking from here, the D equivelant would, I suppose, be this...
> 
> class A {
>   protected void method () {}
> }
> 
> class B : A {
>   override protected void method () {
>     (cast(A) this).method();
>   }
> }
> 
> 
> And once again the upcoming macros feature could help out some.  I'm 
> guessing at exactly what the macro syntax will be, in that I'm unsure 
> they will have tuples like what I'm using here.
> 
> macro MUpCall (Ancestor, Method, Args ...) {
>   (cast(Ancestor) this).method(Args);
> }
> 
> class A {
>   protected void method (int i) {}
> }
> 
> class B : A {
>   override protected void method (int i) {
>     MUpCall(A, method, i);
>   }
> }
> 
> -- Chris Nicholson-Sauls

This will, as mentioned cause infinit recursion.  Here's a syntax 
suggestion.  What about?

super.super.method();

It also would be nice if we could do things like:

A.super.method(); //Parent of A
This would help avoid issues when you insert a new class inheritance 
between A and B.

Although I'm not sure how common that would be.


More information about the Digitalmars-d-learn mailing list