Re: putting more smarts into a == b

2009-09-27 Thread Ary Borenszweig
Andrei Alexandrescu wrote: Frank Benoit wrote: Andrei Alexandrescu schrieb: Frank Benoit wrote: Andrei Alexandrescu schrieb: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to

Re: putting more smarts into a == b

2009-09-27 Thread Andrei Alexandrescu
Robert Jacques wrote: On Sun, 27 Sep 2009 09:11:38 -0400, Andrei Alexandrescu wrote: Robert Jacques wrote: On Sat, 26 Sep 2009 21:32:13 -0400, Andrei Alexandrescu wrote: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals

Re: putting more smarts into a == b

2009-09-27 Thread Robert Jacques
On Sun, 27 Sep 2009 09:11:38 -0400, Andrei Alexandrescu wrote: Robert Jacques wrote: On Sat, 26 Sep 2009 21:32:13 -0400, Andrei Alexandrescu wrote: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it sh

Re: putting more smarts into a == b

2009-09-27 Thread Steven Schveighoffer
On Sun, 27 Sep 2009 10:32:29 -0400, Andrei Alexandrescu wrote: Frank Benoit wrote: Andrei Alexandrescu schrieb: Frank Benoit wrote: Andrei Alexandrescu schrieb: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I arg

Re: putting more smarts into a == b

2009-09-27 Thread Frank Benoit
Andrei Alexandrescu schrieb: > Frank Benoit wrote: >> In DWT, I cast always first to Object. >> Java> if( intf1.equals(intf2) ){ >> D1.0> if( ((cast(Object)intf1).opEquals( cast(Object)intf2 )){ > > I think in D the cast is inserted automatically. Walter? > > Andrei there is a related bug report

Re: putting more smarts into a == b

2009-09-27 Thread Andrei Alexandrescu
Frank Benoit wrote: Andrei Alexandrescu schrieb: Frank Benoit wrote: Andrei Alexandrescu schrieb: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to an (imaginary/inlined) func

Re: putting more smarts into a == b

2009-09-27 Thread Frank Benoit
Andrei Alexandrescu schrieb: > Frank Benoit wrote: >> Andrei Alexandrescu schrieb: >>> Consider two objects a and b with a of class type. Currently, the >>> expression a == b is blindly rewritten as a.opEquals(b). I argue it >>> should be rewritten into a call to an (imaginary/inlined) function >>>

Re: putting more smarts into a == b

2009-09-27 Thread Andrei Alexandrescu
Frank Benoit wrote: Andrei Alexandrescu schrieb: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to an (imaginary/inlined) function equalObjects(a, b), with the following definit

Re: putting more smarts into a == b

2009-09-27 Thread Andrei Alexandrescu
Robert Jacques wrote: On Sat, 26 Sep 2009 21:32:13 -0400, Andrei Alexandrescu wrote: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to an (imaginary/inlined) function equal

Re: putting more smarts into a == b

2009-09-27 Thread Christopher Wright
Jarrett Billingsley wrote: On Sat, Sep 26, 2009 at 9:32 PM, Andrei Alexandrescu wrote: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to an (imaginary/inlined) function equalOb

Re: putting more smarts into a == b

2009-09-27 Thread Frank Benoit
Frank Benoit schrieb: > What about interfaces? I mean, this is a point that annoyes me a lot in D, that interfaces (instances) cannot be treated like objects. I cannot do if( someiface == someobj ){ ... } With that technique, the compiler could do a dynamic cast to Object in place, do the null c

Re: putting more smarts into a == b

2009-09-27 Thread Frank Benoit
Andrei Alexandrescu schrieb: > Consider two objects a and b with a of class type. Currently, the > expression a == b is blindly rewritten as a.opEquals(b). I argue it > should be rewritten into a call to an (imaginary/inlined) function > equalObjects(a, b), with the following definition: > > bool

Re: putting more smarts into a == b

2009-09-26 Thread Robert Jacques
On Sat, 26 Sep 2009 21:32:13 -0400, Andrei Alexandrescu wrote: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to an (imaginary/inlined) function equalObjects(a, b), with

Re: putting more smarts into a == b

2009-09-26 Thread Ary Borenszweig
Andrei Alexandrescu wrote: Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to an (imaginary/inlined) function equalObjects(a, b) Definitely!

Re: putting more smarts into a == b

2009-09-26 Thread bearophile
Andrei Alexandrescu: > This hoists the identity test outside the opEquals call and also deals > with null references. What do you think? I like it, is also saves some boring code. Bye, bearophile

Re: putting more smarts into a == b

2009-09-26 Thread Jarrett Billingsley
On Sat, Sep 26, 2009 at 9:32 PM, Andrei Alexandrescu wrote: > Consider two objects a and b with a of class type. Currently, the expression > a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten > into a call to an (imaginary/inlined) function equalObjects(a, b), with the >

putting more smarts into a == b

2009-09-26 Thread Andrei Alexandrescu
Consider two objects a and b with a of class type. Currently, the expression a == b is blindly rewritten as a.opEquals(b). I argue it should be rewritten into a call to an (imaginary/inlined) function equalObjects(a, b), with the following definition: bool equalObjects(T, U)(T a, U b) if (is(T