www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - the 'this' keyword

reply Ant <duitoolkit yahoo.ca> writes:
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
May 29 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
May 29 2004
next sibling parent DemmeGod <me demmegod.com> writes:
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

May 30 2004
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
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
Jun 01 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
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
Jun 09 2004
parent Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 I don't want to restart this discussion, I cleary lost it
 I just want to show here I was comming from:
 
 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.

aha. I see. This does have the potential to break invariants. It is (or it should be) intended to be a last resort. Ideally, the programmer would just make the method in question final, thereby evading this whole mess. -- andy
Jun 09 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
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
Jun 09 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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

May 29 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
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
May 29 2004
parent "Walter" <newshound digitalmars.com> writes:
"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().
May 29 2004
prev sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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.
Jun 01 2004
parent Ant <Ant_member pathlink.com> writes:
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
Jun 01 2004