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