www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Default implementation of opEquals

reply Mark <smarksc gmail.com> writes:
I'm going over the Object class methods and I have a few concerns 
about the opEquals method.

First, what should be the default implementation of opEquals? The 
specification (see 
https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

"If opEquals is not specified, the compiler provides a default 
version that does member-wise comparison"

But this doesn't appear to be the case (at least with dmd). So I 
went and checked the module in 
https://github.com/dlang/druntime/blob/master/src/object.d. It 
implements opEquals by comparing references (obj1 is obj2), not 
by member-wise comparison.

Wouldn't member-wise comparison be a more intuitive default?
Oct 07 2016
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
 I'm going over the Object class methods and I have a few 
 concerns about the opEquals method.

 First, what should be the default implementation of opEquals? 
 The specification (see 
 https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"

 But this doesn't appear to be the case (at least with dmd). So 
 I went and checked the module in 
 https://github.com/dlang/druntime/blob/master/src/object.d. It 
 implements opEquals by comparing references (obj1 is obj2), not 
 by member-wise comparison.

 Wouldn't member-wise comparison be a more intuitive default?
For structs it provides memberwise comparison for classes it uses pointer-identity
Oct 07 2016
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
 I'm going over the Object class methods and I have a few 
 concerns about the opEquals method.

 First, what should be the default implementation of opEquals? 
 The specification (see 
 https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"

 But this doesn't appear to be the case (at least with dmd). So 
 I went and checked the module in 
 https://github.com/dlang/druntime/blob/master/src/object.d. It 
 implements opEquals by comparing references (obj1 is obj2), not 
 by member-wise comparison.

 Wouldn't member-wise comparison be a more intuitive default?
This is a problem with the spec that needs to be fixed. It's well known that member wise comparison default is for structs and objects just compare the reference. I believe this has always been the intended behavior.
Oct 07 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"
That's referring to structs. For classes, it gives an identity comparison function here: https://dlang.org/spec/operatoroverloading.html#equals
 Wouldn't member-wise comparison be a more intuitive default?
Classes are supposed to represent encapsulated objects where you don't look at the members from the outside, so that might be surprising in a different way.
Oct 07 2016
parent reply Mark <smarksc gmail.com> writes:
On Friday, 7 October 2016 at 12:34:34 UTC, Adam D. Ruppe wrote:
 On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
 "If opEquals is not specified, the compiler provides a default 
 version that does member-wise comparison"
That's referring to structs. For classes, it gives an identity comparison function here: https://dlang.org/spec/operatoroverloading.html#equals
 Wouldn't member-wise comparison be a more intuitive default?
Classes are supposed to represent encapsulated objects where you don't look at the members from the outside, so that might be surprising in a different way.
Okay, that makes sense. I find it slightly annoying that the default opCmp throws an exception whereas the default opEquals doesn't, but if both of these functions are to be removed from Object, as Jonathan M Davis stipulates, then all of this is a non-issue.
Oct 07 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 07, 2016 13:41:00 Mark via Digitalmars-d wrote:
 I find it slightly annoying that the default opCmp throws an
 exception whereas the default opEquals doesn't, but if both of
 these functions are to be removed from Object, as Jonathan M
 Davis stipulates, then all of this is a non-issue.
It's the plan anyway. It fundamentally doesn't work to have them on Object and be flexible with attributes, so it was decided a while ago that they need to go. Unfortunately, not a lot has been done to get there yet, and what has been done hasn't been merged. Fortunately, one of the major issues is that (if I understand correctly) we really need a templatized AA implementantion to be able to remove the functions from Object, and a fair bit of work _has_ gone towards that, and it looks like we may have it in the reasonably near future. But there's still plenty to figure out out about how we go about this, because a big part of the problem is how to do it without breaking code. Once the groundwork has been laid, we could easily just remove the functions, but that would break a lot of code, which we obviously don't want. So, at some point here, all of that is going to need to be discussed and a plan formed. For now though, it sounds like the AA implementation is coming along, and there is a PR to templatize opEquals so that it's at least possible to declare opEquals without overriding the one on Object. - Jonathan M Davis
Oct 07 2016
parent Mark <smarksc gmail.com> writes:
On Friday, 7 October 2016 at 14:04:10 UTC, Jonathan M Davis wrote:
 On Friday, October 07, 2016 13:41:00 Mark via Digitalmars-d 
 wrote:
 [...]
It's the plan anyway. It fundamentally doesn't work to have them on Object and be flexible with attributes, so it was decided a while ago that they need to go. Unfortunately, not a lot has been done to get there yet, and what has been done hasn't been merged. Fortunately, one of the major issues is that (if I understand correctly) we really need a templatized AA implementantion to be able to remove the functions from Object, and a fair bit of work _has_ gone towards that, and it looks like we may have it in the reasonably near future. [...]
Wish I could help, but I'm still a D newbie. :x
Oct 07 2016
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, October 07, 2016 12:04:09 Mark via Digitalmars-d wrote:
 I'm going over the Object class methods and I have a few concerns
 about the opEquals method.

 First, what should be the default implementation of opEquals? The
 specification (see
 https://dlang.org/spec/operatoroverloading.html#eqcmp) reads:

 "If opEquals is not specified, the compiler provides a default
 version that does member-wise comparison"

 But this doesn't appear to be the case (at least with dmd). So I
 went and checked the module in
 https://github.com/dlang/druntime/blob/master/src/object.d. It
 implements opEquals by comparing references (obj1 is obj2), not
 by member-wise comparison.

 Wouldn't member-wise comparison be a more intuitive default?
The current behavior is what it's always been and actually is consistent with what Java and C# do. Not to mention, we're actually planning to eventually remove opEquals from Object. https://issues.dlang.org/show_bug.cgi?id=9769 Speaking of which, this PR to templatize the free function version of opEquals needs some folks to review it and merge it: https://github.com/dlang/druntime/pull/1439 It's just been languishing even though it's theoretically ready to go and has been for months. - Jonathan M Davis
Oct 07 2016