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
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
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
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
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
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
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
>>>
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
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
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
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
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
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
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!
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
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
>
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
17 matches
Mail list logo