www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Making `object.opEquals' replaceable

reply "Manfred Nowak" <svv1999 hotmail.com> writes:
According to the specs
   http://dlang.org/operatoroverloading.html#equals
`object.opEquals' denies to call the `opEquals'-function tailored 
for the class of two objects `a' an `b' if for those objects `a 
is b' holds.

Although this seems resonable and reduces boiler-plate it makes 
it impossible to implement a side-effect for those cases.

I do not believe, that there is good reason to disallow 
side-effects in those cases. Therefore a mechanism to enable such 
side-effects should be implemented.

-manfred
May 07 2015
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 7 May 2015 at 14:37:14 UTC, Manfred Nowak wrote:

 According to the specs
   http://dlang.org/operatoroverloading.html#equals
 `object.opEquals' denies to call the `opEquals'-function 
 tailored for the class of two objects `a' an `b' if for those 
 objects `a is b' holds.

 Although this seems resonable and reduces boiler-plate it makes 
 it impossible to implement a side-effect for those cases.

 I do not believe, that there is good reason to disallow 
 side-effects in those cases. Therefore a mechanism to enable 
 such side-effects should be implemented.


And why not just use another function instead of opEquals for 
what you want?

- Jonathan M Davis
May 07 2015
parent reply "Manfred Nowak" <svv1999 hotmail.com> writes:
Jonathan M Davis wrote:


 And why not just use another function instead of opEquals for 
 what you want?


Because the local `opEquals' _is_ the overload-function for `==' 
and `!='.

I guess that your "another function"-opinion holds for every form 
of overloading.

-manfred
May 08 2015
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 8 May 2015 at 17:00:00 UTC, Manfred Nowak wrote:

 Jonathan M Davis wrote:


 And why not just use another function instead of opEquals for 
 what you want?


 Because the local `opEquals' _is_ the overload-function for 
 `==' and `!='.

 I guess that your "another function"-opinion holds for every 
 form of overloading.


In general, D is far more restrictive in how it defines 
overloaded operators than C++ is. This helps enforce the 
correctness and consistency of such operators and reduces how 
much code has to be written. Occasionally, that means that there 
are things that you can do in C++ with overloaded operators that 
you cannot do in D with overloaded operators, and perhaps that is 
a loss, but on the whole, it's well worth the gains (e.g. by 
defining only opEquals and opCmp, you get the whole suite of 
overloaded operators, whereas in C++, you'd have to implement 
each and every one of them individually, which is both far more 
verbose and far more error-prone).

So, if an overloaded operator does not work with what you're 
trying to do, then you need to use a function of your own to 
implement it.

- Jonathan M Davis
May 08 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 08 May 2015 16:59:59 +0000, Manfred Nowak wrote:


 Jonathan M Davis wrote:
=20

 And why not just use another function instead of opEquals for what you
 want?


=20
 Because the local `opEquals' _is_ the overload-function for `=3D=3D' and
 `!=3D'.
=20
 I guess that your "another function"-opinion holds for every form of
 overloading.
=20
 -manfred


i'd be VERY surprised if `=3D=3D` or `!=3D` does any mutation. and i (like =
most=20
programmers) don't like such surprises in code.=
May 08 2015
parent "Manfred Nowak" <svv1999 hotmail.com> writes:
ketmar wrote:

 i'd be VERY surprised if `==` or `!=` does any mutation. and i 
 (like most programmers) don't like such surprises in code.


The side effect I used was logging. And me _was_ surprised not to 
get the expected number of log-lines.

-manfred
May 09 2015
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Thursday, 7 May 2015 at 14:37:14 UTC, Manfred Nowak wrote:

 According to the specs
   http://dlang.org/operatoroverloading.html#equals
 `object.opEquals' denies to call the `opEquals'-function 
 tailored for the class of two objects `a' an `b' if for those 
 objects `a is b' holds.

 Although this seems resonable and reduces boiler-plate it makes 
 it impossible to implement a side-effect for those cases.

 I do not believe, that there is good reason to disallow 
 side-effects in those cases. Therefore a mechanism to enable 
 such side-effects should be implemented.

 -manfred


Having the base Object method check for 'is' itself results in 
not having to make a virtual call in, I would guess, about 40-50% 
of cases or even more. It's a performance benefit.
May 07 2015
parent reply "Manfred Nowak" <svv1999 hotmail.com> writes:
Kapps wrote:

 It's a performance benefit.


There is no proof that every replacing mechanism necessarily 
degrades performance. Please recall, that for implmenting a side 
effect on all checked pairs of elements of a class, a virtual 
call is necassary anyway.

-manfred
May 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/8/15 10:11 AM, Manfred Nowak wrote:

 Kapps wrote:

 It's a performance benefit.


 There is no proof that every replacing mechanism necessarily degrades
 performance. Please recall, that for implmenting a side effect on all
 checked pairs of elements of a class, a virtual call is necassary anyway.


The right answer to this is: opEquals is currently not replaceable and 
there are no plans to make it so. D is so flexible, people in this forum 
tend to take it for granted that any theoretical flexibility ought to be 
realized. There is, however, value in drawing boundaries, too.

Manfred, you will need to find other means to achieve what you need to do.


Andrei
May 08 2015
parent "Manfred Nowak" <svv1999 hotmail.com> writes:
Andrei Alexandrescu wrote:

 you will need to find other means


If this is meant to be ex cathedra, then I am quiet.

-manfred
May 08 2015