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

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/ComparingCPPAndCPerformance2.htm .
You'll see why "this" is important from there.

Kind regards

Dejan

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

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.

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

"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.

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

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.

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

Lloyd Dupont Wrote:

> Hi Jesse, this won't work!
> It's my fault in not explaining my problem well though...
> 
> I forget to mention something...
> I'm using property syntax and try to call the method
> 
> Say I have
> =====
> private int _foo;
> @property public int Foo() { return _foo; }
> @property public void Foo(int value) { _foo = value; }
> =====
> if I call MEMBER(MyClass, "Foo")
> I'd like to do some static test for "int Foo()" and "void Foo(int)"
> 
> So... how will I go on solving that?

I don't remember how to package these up nicely:

void MEMBER(T, string fun)(T m) if(expectedType!(T, fun).valid) {
}

template expectedType(T, string fun) {
	private T s;
	static if(mixin("__traits(compiles, s."~fun~" = 0) && is(typeof(s."~fun~") : int)"))
		enum valid = true;
	else
		enum valid = false;
}

It helped! it's working now! :)
Thanks!

"Jesse Phillips"  wrote in message news:itgg6i$2tf3$1@digitalmars.com...

Lloyd Dupont Wrote:

> Hi Jesse, this won't work!
> It's my fault in not explaining my problem well though...
>
> I forget to mention something...
> I'm using property syntax and try to call the method
>
> Say I have
> =====
> private int _foo;
> @property public int Foo() { return _foo; }
> @property public void Foo(int value) { _foo = value; }
> =====
> if I call MEMBER(MyClass, "Foo")
> I'd like to do some static test for "int Foo()" and "void Foo(int)"
>
> So... how will I go on solving that?

I don't remember how to package these up nicely:

void MEMBER(T, string fun)(T m) if(expectedType!(T, fun).valid) {
}

template expectedType(T, string fun) {
private T s;
static if(mixin("__traits(compiles, s."~fun~" = 0) && is(typeof(s."~fun~") : int)"))
enum valid = true;
else
enum valid = false;
}