from my post on the bugs group:

interface I
{
	void a();
	void b();
}

class A : I
{
	void a()
	{
		printf("A.a\n");
	}

	void b()
	{
		0,typeof(this).a();
		a();
	}
}

class B : A
{
	void a()
	{
		printf("B.a\n");
	}

}

int main(char[][] args)
{
	I b = new B();

	b.b();

	return 0;
}

it prints:
A.a
B.a

I guess it's the expected result (as much as it displeases me).
but it shows another problem with the sintax,
(This new problem is not unrelated with the
constructores being named "this".
There is a big confusion on D with the "this" keyword)

"this" should represent the object not something else.
on the line "0,typeof(this).a();", "this" clearly does not represent the
object.

the sintax is not good.
the idea is not good.

Ant

Ant wrote:

> "this" should represent the object not something else.
> on the line "0,typeof(this).a();", "this" clearly does not represent the
> object.

It's perfectly consistent: 'this' is the object.  typeof(this) is whatever type it happens to be cast as at the moment.  The statement could be rewritten as A.a();, except in cases where you don't know what type 'this' is, like templated classes and mixins.

> the sintax is not good.
> the idea is not good.

It's just another mechanism that lets a programmer do the Wrong Thing when they really need to.

 -- andy

"Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.05.29.22.49.16.608272@yahoo.ca...
> I guess it's the expected result (as much as it displeases me).
> but it shows another problem with the sintax,
> (This new problem is not unrelated with the
> constructores being named "this".
> There is a big confusion on D with the "this" keyword)
>
> "this" should represent the object not something else.
> on the line "0,typeof(this).a();", "this" clearly does not represent the
> object.

The "0," is needed to work around a compiler bug, it'll be fixed in the next
update. The typeof(this).a() is semantically identical to (for your example)
A.a(), which you can use instead. typeof(this) just is a handy way to get at
the type in generic templates or mixins without having to add another
parameter to the template.

> the sintax is not good.
> the idea is not good.
>
> Ant
>

On Sat, 29 May 2004 17:01:51 -0700, Walter wrote:

> 
> "Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.05.29.22.49.16.608272@yahoo.ca...
>> I guess it's the expected result (as much as it displeases me).
>> but it shows another problem with the sintax,
>> (This new problem is not unrelated with the
>> constructores being named "this".
>> There is a big confusion on D with the "this" keyword)
>>
>> "this" should represent the object not something else.
>> on the line "0,typeof(this).a();", "this" clearly does not represent the
>> object.
> 
> The "0," is needed to work around a compiler bug, it'll be fixed in the next update.

I understand that, I should have warn others that don't follow the bugs group.

> The typeof(this).a() is semantically identical to (for your example)
> A.a(), which you can use instead. typeof(this) just is a handy way to get at
> the type in generic templates or mixins without having to add another
> parameter to the template.

yes, I found a similar limitation on my experiments on templates.

however in my example the object is an instance of class B
and typeof(this) seems to get class A.
It's confusing, it's not right, the sintax is wrong
(I'm I repeating myself?).

A.a() to me refers to a static member
and is not context free.
(where is that "So long!" guy when we need him?)

would it be possible or desirable to limit this thing to templates?

now I'm gonna quote Kris:
"Am I completely off base here?"

As Andy reminded me D is a language that allow us to do the
"Wrong Thing", or as you say on the overview
D is "a practical language for practical programmers".

Ant

"Ant" <duitoolkit@yahoo.ca> wrote in message news:pan.2004.05.30.00.40.01.326309@yahoo.ca...
> however in my example the object is an instance of class B
> and typeof(this) seems to get class A.
> It's confusing, it's not right, the sintax is wrong
> (I'm I repeating myself?).
>
> A.a() to me refers to a static member
> and is not context free.
> (where is that "So long!" guy when we need him?)
>
> would it be possible or desirable to limit this thing to templates?

The issue here is the desire to get at the local implementation of a virtual function rather than the most derived version. The A.a() syntax is chosen because it is equivalent to the way this is done in C++ with A::a().

There is another way to the the class of an object, such as this, so that
one could, in this example, have b() call B.b()?

John

On Sat, 29 May 2004 16:18:17 -0700, Andy Friesen wrote:

> Ant wrote:
> 
>> "this" should represent the object not something else. on the line
>> "0,typeof(this).a();", "this" clearly does not represent the object.
> 
> It's perfectly consistent: 'this' is the object.  typeof(this) is whatever type it happens to be cast as at the moment.  The statement could be rewritten as A.a();, except in cases where you don't know what type 'this' is, like templated classes and mixins.
> 
>> the sintax is not good.
>> the idea is not good.
> 
> It's just another mechanism that lets a programmer do the Wrong Thing when they really need to.
> 
>   -- andy

In article <c9b5e1$mho$1@digitaldaemon.com>, Andy Friesen says...
>
>Ant wrote:
>
>> "this" should represent the object not something else.
>> on the line "0,typeof(this).a();", "this" clearly does not represent the
>> object.
>
>It's perfectly consistent: 'this' is the object.  typeof(this) is whatever type it happens to be cast as at the moment.

aaahhhhhh... cast at the moment.
It still hard to get it at the conceptual level.
but I guess I can get use to the idea - not that I plan to use it.

> The statement
>could be rewritten as A.a();, except in cases where you don't know what type 'this' is, like templated classes and mixins.
>
>> the sintax is not good.
>> the idea is not good.
>
>It's just another mechanism that lets a programmer do the Wrong Thing when they really need to.

I would replace "really need to" by "don't know better". ;) probably there are situations when it the best way to do it, It's my limitation I can't imagine those.

Ant

Ant wrote:
(...)
> I guess it's the expected result (as much as it displeases me).
> but it shows another problem with the sintax,
> (This new problem is not unrelated with the
> constructores being named "this".
> There is a big confusion on D with the "this" keyword)

Where is the problem: "this" is a pointer to the object. As always with polymorphic objects, the type of a object reference need not be the type of the object itself. Thy type of "this" is always a reference to the surrounding class. If a routine is inherited, that does not affect the internals of the routine.

"typeof" always returns the (compile-time) type of the reference, not the
(runtime) type of the object.

To me, that makes perfect sense.

In article <c9icn0$1lkk$1@digitaldaemon.com>, Norbert Nemec says...
>
>Ant wrote:
>(...)
>> I guess it's the expected result (as much as it displeases me).
>> but it shows another problem with the sintax,
>> (This new problem is not unrelated with the
>> constructores being named "this".
>> There is a big confusion on D with the "this" keyword)
>
>Where is the problem: "this" is a pointer to the object. As always with polymorphic objects, the type of a object reference need not be the type of the object itself. Thy type of "this" is always a reference to the surrounding class. If a routine is inherited, that does not affect the internals of the routine.
>
>"typeof" always returns the (compile-time) type of the reference, not the
>(runtime) type of the object.
>
>To me, that makes perfect sense.
>

Thank you, that was exactly my problem, you guys are right.

Ant

In article <c9b5e1$mho$1@digitaldaemon.com>, Andy Friesen says...
>
>Ant wrote:
>
>> "this" should represent the object not something else.
>> on the line "0,typeof(this).a();", "this" clearly does not represent the
>> object.
>
>It's perfectly consistent: 'this' is the object.  typeof(this) is whatever type it happens to be cast as at the moment.

I don't want to restart this discussion, I cleary lost it
I just want to show here I was comming from:

I checked on java a couple days ago and
this is what I expect from "this":
(of course I shouldn't bring expectation from other languages)

<java>
class A
{
String whoAmI()
{
// the keyword "this" is redundant here
return this.getClass().getName();
}
}

public class AB extends A
{
public static void main(String [] args)
{
A a = new AB();
System.out.println("I am "+a.whoAmI());
}
}
</java>
<console>
C:\j2sdk1.4.2_04\bin>javac AB.java

C:\j2sdk1.4.2_04\bin>java AB
I am AB

</console>

So I insist that D is now "sometimes polymorphic"
or "not garantied to be polymorphic".
Virtual functions are not garantied to be called through the virtual
table even if the access modifier seems to indicate that.

the example (similar) posted on this subject is a good one:

class A
{

public int get()
{
return 14;
}

public int[] multiGet()
{
int[] ii;
ii ~= typeof(this).get(); // bad, bad...
ii ~= typeof(this).get(); // bad, bad...
}
}

class B : A
{
int numberOfGets = 0;
public int get()
{
// you whish! this is not garantied to work on D
// but there is nothing on the API of class A that
// denotes that!
++numberOfGets;
return super.get();
}
}

well, if I want a perfect language I'll have to write it.

Ant