> I can see how the wording is confusing, but that statement is somewhat out of context. What it really means is that == and != *should* be comparing the contents.
>
> It is an explanatory statement as to why you cannot call
>
> obj == null;
>
> Because this translates to obj.opEquals(null), if obj is null, then it crashes (well, at least it used to).
>
> The true definition of the default is here:
>
> https://github.com/schveiguy/druntime/blob/master/src/object_.d#L107
>
> -Steve

Doesn't TDPL talk about that the correct behaviour is this one

https://github.com/schveiguy/druntime/blob/master/src/object_.d#L162

and a == b should be rewritten to opEquals(a, b) which will fallback to identity
if a user defined class has no opEquals defined?


Could anyone clarify what the actual and intended behaviour is?

On Saturday, 3 January 2015 at 16:39:05 UTC, Jonathan Marler wrote:
> Using toAddrString results in the following steps:

> 1. Allocate memory for the InternetAddress (GC memory by the way)
> 2. Convert the uint address to an IP Address string
> 3. Convert the ushort port to a string.
> 4. Do steps 1-3 to the second InternetAddress
> 5. Do a string comparision with the two InternetAddresses.

Hmm well, you don't need to convert anything (like ushort to string etc), you can compare the fields between these 2 classes directly:

import std.stdio;
import std.socket;

class myIA : InternetAddress{
    this(in char[] addr, ushort port){
        super(addr, port);
    }
	
    bool opEquals(myIA obj){
        foreach (i, v; this.tupleof) {
            if(v != obj.tupleof[i]){
                return false;
            }
        }
        return true;
    }
}

void main(){
  auto addr1 = new myIA("192.168.0.1", 80);
  auto addr2 = new myIA("192.168.0.1", 80);
  assert(addr1.opEquals(addr2));
}

Overall I understood your point/pain, but unfortunately this is what I could do to manage your problem (I'm using D heavily for a couple months now).

I'll continue looking over this thread to see what the experts will say. :)

Matheus.

On Saturday, 3 January 2015 at 17:26:29 UTC, MattCoder wrote:
> On Saturday, 3 January 2015 at 16:39:05 UTC, Jonathan Marler wrote:
>> Using toAddrString results in the following steps:
>
>> 1. Allocate memory for the InternetAddress (GC memory by the way)
>> 2. Convert the uint address to an IP Address string
>> 3. Convert the ushort port to a string.
>> 4. Do steps 1-3 to the second InternetAddress
>> 5. Do a string comparision with the two InternetAddresses.
>
> Hmm well, you don't need to convert anything (like ushort to string etc), you can compare the fields between these 2 classes directly:
>
> import std.stdio;
> import std.socket;
>
> class myIA : InternetAddress{
>     this(in char[] addr, ushort port){
>         super(addr, port);
>     }
> 	
>     bool opEquals(myIA obj){
>         foreach (i, v; this.tupleof) {
>             if(v != obj.tupleof[i]){
>                 return false;
>             }
>         }
>         return true;
>     }
> }
>
> void main(){
>   auto addr1 = new myIA("192.168.0.1", 80);
>   auto addr2 = new myIA("192.168.0.1", 80);
>   assert(addr1.opEquals(addr2));
> }
>
> Overall I understood your point/pain, but unfortunately this is what I could do to manage your problem (I'm using D heavily for a couple months now).
>
> I'll continue looking over this thread to see what the experts will say. :)
>
> Matheus.

My problem isn't comparing the two addresses..I can do that using

(addr1.addr == addr2.addr && addr1.port == addr2.port)

my question was, should the InterenetAddress class have an opEquals or an opCmp or were they ommitted on purpose?

On Saturday, 3 January 2015 at 17:37:19 UTC, Jonathan Marler wrote:
> my question was, should the InterenetAddress class have an opEquals or an opCmp or were they ommitted on purpose?

Yes I understood your problem and like I said on the previous post I'm interested on the answer from the experts too. :)

Matheus.

On Saturday, 3 January 2015 at 16:33:56 UTC, Jonathan Marler wrote:
> So what is the right way to compare the contents of 2 classes?  I thought it was to implement an opEquals method.  It pains me to see people using the toAddrString function to compare Address classes:(  This is so inefficient and unnecessary.

Sure, someone should make a pull and implement opEquals for the Address classes, maybe also opHash.

On 01/03/2015 05:42 PM, Tobias Pankrath wrote:
> Could anyone clarify what the actual and intended behaviour is?

This [1] is the implementation and it calls opEquals. If that's not overriden, the default [2] will use identity comparison.

[1]: https://github.com/D-Programming-Language/druntime/blob/b3a8032e3960480a1588b3d1a4491808b4502d67/src/object_.d#L162
[2]: https://github.com/D-Programming-Language/druntime/blob/b3a8032e3960480a1588b3d1a4491808b4502d67/src/object_.d#L109

On 01/04/2015 12:45 AM, Martin Nowak wrote:
> Sure, someone should make a pull and implement opEquals for the Address
> classes, maybe also opHash.

In the meantime addr1.tupleof == addr2.tupleof is a useful workaround, but it can't handle polymorphism.

On Saturday, 3 January 2015 at 23:46:01 UTC, Martin Nowak wrote:
> On Saturday, 3 January 2015 at 16:33:56 UTC, Jonathan Marler wrote:
>> So what is the right way to compare the contents of 2 classes?
>>  I thought it was to implement an opEquals method.  It pains me to see people using the toAddrString function to compare Address classes:(  This is so inefficient and unnecessary.
>
> Sure, someone should make a pull and implement opEquals for the Address classes, maybe also opHash.

I've made a pull request (https://github.com/D-Programming-Language/phobos/pull/2839#discussion_r22435562).  I haven't used opEquals that much in D so I'm not super familiar with it.  It does concern me a little though.  I'm wondering why the type specific opEquals isn't called first before the generic opEquals(Object) method when using the '==' operator.  According to the documentation, (a == b), where a and b are classes, is rewritten as ".object.opEquals(a, b)".  I'm just wondering why there has to be overhead when using the '==' operator.  Instead, the type specific opEquals operator should be called, then if it does not exist, then the generic ".object.opEquals" method should be used.  Why isn't it done this way?

On Sunday, 4 January 2015 at 00:13:21 UTC, Martin Nowak wrote:
> On 01/04/2015 12:45 AM, Martin Nowak wrote:
>> Sure, someone should make a pull and implement opEquals for the Address
>> classes, maybe also opHash.
>
> In the meantime addr1.tupleof == addr2.tupleof is a useful workaround, but it can't handle polymorphism.

Ah I hadn't thought of using tupleof, works nicely.  It will compare the entire address struct (sockaddr_in) which is a few extra comparisons then what is needed but that is pretty close.  I'll try to think of tupleof more often in the future. Thanks.