Is there any particular reason to disallow multiple "alias this" ?

<code>
import std.stdio;

class A {
}

class B {
}

class C {
	private A a;
	alias a this;
	private B b;
	alias b this;//compile-time error

	this() {
		a = new A();
		b = new B();
	}
}

void main() {
	C c = new C();
}
</code>


I can implement "multiple" interfaces and extend "single" base class in Java like this:

<code>
class C extends BaseClass implements Interface1, Interface2, ...
</code>

But I can't do it using D. Code like the following does not be compiled.

<code>
class C : BaseClass, Interface1, Interface2, ...
</code>

Is there any particular reason? What's the difference between Java's approach and single "alias this"?

Deokjae Lee wrote:

> But I can't do it using D. Code like the following does not be compiled.
> 
> <code>
> class C : BaseClass, Interface1, Interface2, ...
> </code>
> 
> Is there any particular reason? What's the difference between Java's approach and single "alias this"?

Huh? This compiles:

class Foo : Base, I1, I2{ }
class Base {}
interface I1 {}
interface I2 {}

As for alias this, it's not about dynamic polymorphism like class inheritance. All it does is forward unresolved method calls to the alias this'ed member.


Tomek

Deokjae Lee <asitdepends@gmail.com> wrote:

> Is there any particular reason to disallow multiple "alias this" ?

Yes - the fact that it's not yet implemented. (it's on the drawing board
, just not quite there yet.)


> I can implement "multiple" interfaces and extend "single" base class in
> Java like this:
>
> <code>
> class C extends BaseClass implements Interface1, Interface2, ...
> </code>
>
> But I can't do it using D. Code like the following does not be compiled.
>
> <code>
> class C : BaseClass, Interface1, Interface2, ...
> </code>
>
> Is there any particular reason?

Uhm... That's supposed to work.


> What's the difference between Java's approach and single "alias this"?

Java's (and D's) interfaces is something quite different from alias
this. Alias this is a simplistic (though powerful) kind of subtyping
where the class or struct can embed a different type, and behave as if
it is one, though without polymorphism.

-- 
Simen

Thank you for the reply.
Actually I tested a code like this.

//interfaces first, base class last
class Foo : I1, I2, Base {}

This doesn't compile.
I didn't know the order of base class and interfaces matter.


> As for alias this, it's not about dynamic polymorphism like class inheritance. All it does is forward unresolved method calls to the alias this'ed member.

I'm reading TDPL and it says "alias this" in a relation with multiple subtyping. Polymorphism can be achieved using a nested class extending the base class and implicit conversion. So, I can't get the role of the "alias this" differentiated from inheritance.

And...

import std.stdio;

class A {
	void func() {
		writeln("A");
	}
}

class B : A {
	override void func() {
		writeln("B");
	}
}

class C {
	private B b;
	alias b this;

	this() {
		b = new B();
	}
}

void main() {
	C c = new C();
	c.func();
	A a = c;
	a.func();
}

The output is the following.

B
zsh: segmentation fault  ./Test3

Hmm... Are the last two lines of main illegal?

Deokjae Lee:

> //interfaces first, base class last
> class Foo : I1, I2, Base {}
> 
> This doesn't compile.
> I didn't know the order of base class and interfaces matter.

If not already present, that looks good for Bugzilla.

> The output is the following.
> 
> B
> zsh: segmentation fault  ./Test3

Currently "alias this" is a quite buggy feature.
You can try to reduce that code to the minimal, and then you can add it to Bugzilla.
In my opinion "alias this" (as typedef in past) is mostly useful/designed for structs, that don't have inheritance. "alias this" is a feature a bit dirty.

Bye,
bearophile

On Sun, 25 Jul 2010 10:53:51 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
> Deokjae Lee:
> 
> > //interfaces first, base class last
> > class Foo : I1, I2, Base {}
> > 
> > This doesn't compile.
> > I didn't know the order of base class and interfaces matter.
> 
> If not already present, that looks good for Bugzilla.

That's as specified in the language spec: http://digitalmars.com/d/2.0/class.html#BaseClassList

You could argue that it shouldn't be that way, but it's correct behavior as the language stands now.