• Mike Capp <mike.capp gmail.com> Aug 12 2005
• Dejan Lekic <leka entropy.tmok.com> Aug 12 2005
• Mike Capp <mike.capp gmail.com> Aug 13 2005
• Dejan Lekic <leka entropy.tmok.com> Aug 14 2005
• Hasan Aljudy <hasan.aljudy gmail.com> Aug 12 2005
• "Ben Hinkle" <ben.hinkle gmail.com> Aug 13 2005
• Mike Capp <mike.capp gmail.com> Aug 13 2005
• Burton Radons <burton-radons smocky.com> Aug 13 2005

Mike Capp <mike.capp gmail.com> writes:

OK, C++ does it that way, but only for hysterical raisins (i.e. references
hadn't been added to the language at the time).

Returning *this from an op*Assign feels... warty. 

cheers
Mike

Dejan Lekic <leka entropy.tmok.com> writes:

Mike, check how polimorphism is made in OO languages, and how is it
implemented in C, than You'll know why is "this" a pointer. And it should
stay like that.
About references... they are not "invented", or something new - references
are just some compiler optimisations, and they also use pointers behind the
scenes. :) Here is one really good article which explains v-tables,
polimorphism, etc:
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPP
ndCPerformance2.htm .
You'll see why "this" is important from there.

Kind regards

Dejan

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  

Mike Capp <mike.capp gmail.com> writes:

In article <ddjlft$1u4q$1 digitaldaemon.com>, Dejan Lekic says...
Mike, check how polimorphism is made in OO languages, and how is it
implemented in C, than You'll know why is "this" a pointer.


Yes, I know how vtables work. That doesn't mean that "this" needs pointer
_syntax_. C# manages to provide a perfectly good "this" and doesn't even _have_
pointers. For C++, see for example
http://www.research.att.com/~bs/bs_faq2.html#this (Bjarne's talking about C++'s
reference concept, which isn't the same thing that D means by the word).

In fact, I've just been playing a bit more and the wart isn't quite where I
thought it was - "this" is only a pointer in struct methods, because D structs
don't support reference semantics. Hence:

# class C { C get() { return this; } } 
# struct S { S get() { return *this; } } 

I suppose that makes the rationale clearer, but it does still feel a bit warty.

I'd also respectfully submit that 

# class C { void set(C c) { this = c; } }

ought really to be a compiler error of some sort, as opposed to just working ;-)

cheers
Mike

Dejan Lekic <leka entropy.tmok.com> writes:

Yeah, but D does have - and IMHO that is a good decision by Mr. Bright. What
I do not understand here is what are you referring by "pointer syntax" ??
PS. if You know about vtables, than You probably know that references also
utilize pointers behind the scenes...

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Mike Capp wrote:
 OK, C++ does it that way, but only for hysterical raisins (i.e. references
 hadn't been added to the language at the time).
 
 Returning *this from an op*Assign feels... warty. 
 
 cheers
 Mike
 
 


Are you suggesting it to be a reference or a "value" i.e. a copy of the 
object?

because the later is meaningless, honestly.

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Mike Capp" <mike.capp gmail.com> wrote in message 
news:ddjhfv$1q5p$1 digitaldaemon.com...
 OK, C++ does it that way, but only for hysterical raisins (i.e. references
 hadn't been added to the language at the time).

 Returning *this from an op*Assign feels... warty.

 cheers
 Mike


If this wasn't a pointer then a method like
 void opPostInc() {
    return this.counter++;
 }
wouldn't be able to change the original object - it would increment the 
counter for a copy of a temporary object.

Note MATLAB OOPS only has value-based objects and so every method needs to 
return this so that the user can reassign it to the variable that contained 
the original object - which sucks for types that really want to be reference 
based. 

Mike Capp <mike.capp gmail.com> writes:

In article <ddkp1h$2u7r$1 digitaldaemon.com>, Ben Hinkle says...
If this wasn't a pointer then a method like
 void opPostInc() {
    return this.counter++;
 }
wouldn't be able to change the original object - it would increment the 
counter for a copy of a temporary object.


Again: I'm not taking issue with the underlying implementation, just with the
syntax. "this" shouldn't be null, shouldn't be assignable, and would ideally be
consistent across structs and classes. That's all.

cheers
Mike

Burton Radons <burton-radons smocky.com> writes:

Should've had that "why is 'this' in struct methods not an inout 
reference".  The current behaviour breaks homogeneity, which screws up 
templating.  It's one of those things where it's going to be changed in 
the future, whether Walter presently agrees or not, and the longer that 
change is delayed the more damage it will cause when it's corrected.

As to assignment to "this", the funny part is that the DMD frontend used 
to do precisely that; I remember seeing it while working on DLI because 
it caused GCC to barf.  I think it's alright for struct at least - I 
don't want to lose the ability to define opAddAssign in a struct as 
"return this = opAdd (other);".  It definitely has a predictable result.