Multiple subtyping with alias this and nested classes

[Max Samukha]

On Tue, 06 Oct 2009 00:52:42 +0200, Yigal Chripun <yigal100 at gmail.com>
wrote:

>>
>I see you want to discuss the details of the renaming mechanism, while I 
>just talked about the general idea itself until now.

Yes, I understand the idea and am trying to imagine it in the context
of D.

>
>we have two cases: regular and mixins.
>for case a it's simple, the class itself lists the renames:
>
>Interface A {
>void foo();
>}
>Interface B {
>void foo();
>}
>
>class C : A, B {
>alias A.foo func1; // or similar syntax to mark the renaming
>alias B.foo func2; // ditto
>
>override void func1() {...} // C.func1 overrides A.foo
>override void func2() {...} // C.func2 overrides B.foo
>}

Ok, that looks good.

>
>case 2, mixins:
>I think some sort of annotations by the programmer is needed.
>
>class C : A, B {
>alias A.foo func1; // or similar syntax to mark the renaming
>alias B.foo func2; // ditto
>
>// hypothetical syntax to connect mixins to interfaces
>// the compiler will apply the rename rules of this class assuming that
>// any references to foo in ImplA are "A.foo" and will be renamed to
>// func1 in C
>// if the mixin explicitly specifies the interface (e.g B.foo) than the 
>// compiler already knows what to map this to.
>mixin ImplA A;
>mixin ImplB B;
>}

This exact syntax won't work but I see your point.

>
>btw, this all can be done in a much simpler way with (hygienic) AST Macros.
>

Sadly (or for the better), we are not going to have macros in the near
future.

>>> I don't think I want non virtual MI in D since it is more trouble than it's worth. but *if* we discuss this, I think my suggested semantics are simpler. The syntax probably can be much better but that's a secondary issue IMO.
>>>
>>
>> It's unrelated to virtual MI. See Sergey Gromov's post. We are
>> discussing this only because it's a real world problem that has no
>> decent solution in D.
>>
>
>I said *non* virtual MI above..

But virtual inheritance is C++'s way to resolve the diamond problem. I
don't think it is related to our discussion in any way.

>This gets more and more complicated - Like I said before, I feel that 
>renaming has easier to understand semantics.

As an exercise, I'm working on a mixin that will allow to subtype a
class and rename/override its virtual functions like this:

class FlippingBlipper
{
   mixin Subclass!(Flipper,
             "nameCollision", "foo") flipper;
   
   this() { flipper.construct(...); }

   void foo() { ... }
}

Save for some bugs in the compiler, it should work reasonably well. Or
maybe not.

>> I think 'alias this' is a powerful feature.
>>
>> Given the constraints like "easy for the compiler writer to implement"
>> and "we have many other things to do", I doubt traits or something
>> like that will be or needs to be in the language.
>
>Alias this is powerful black magic. being powerful doesn't make it any 
>less dark.

Could you explain why it is dark?