One possible solution we've found is to override the Dictionary == method as such:

+ Dictionary{
    == {
        arg otherDict;
        ^(this.asSortedArray == otherDict.asSortedArray);
    }   
}

This produces the expected behavior; there may be better implementations.

Interesting. This is worth some discussion, and would be a significant API change, but I don't have any opinion yet. The only thing I'll say for now is that I would be happy to write a C++ primitive for any new method, because whatever SC implementation would be used would undoubtedly be very slow.

Ouch ouch ouch!

Discussion of API changes usually happens on the mailing list ( https://supercollider.github.io/community/mailing-lists.html ) -- maybe we can discuss the changes there?

Should I get the ball rolling over on the SC mailing list (sc-devs I'm assuming)?

The case is pretty uncontroversial, I'd expect, even if it is a breaking API change. If anyone has used == on dictionaries, she will have been surprised anyhow.

The implementation, however, is something to debate. (think parent and proto envirs etc.)
I'd suggest a "behavioral" definition a bit like:

== { |that|
	if(that.isKindOf(this.class).not) { ^false };
	this.keysValuesDo { |key, val|
		if(that.at(key) != val) { ^false }
	};
	that.keysValuesDo { |key, val|
		if(this.at(key) != val) { ^false }
	};
	^true

}

this can be slow in some circumstances, so an extra primitive is a good idea.

I would suggest checking the number of entries too before iterating. Also, I don't think there is a reason to iterate over both dictionary key-sets.

== { |that|
	if(that.isKindOf(this.class).not) { ^false };
	if(that.keys.size != this.keys.size) { ^false };
	that.keysValuesDo { |key, val|
		if(this.at(key) != val) { ^false }
	};
	^true
}

The implementation is trivial, and it should be in C++. Any SC implementation is likely to be an order of magnitude slower.

Note that changing this would affect all of Dictionary's subclasses:

• IdentityDictionary
• Environment
• NodeMap
• Event
• ProxyNodeMap

I've emailed the sc-dev list :)

once the implementation for Dictionary is done, I'll add the necessary additions to the subclasses. Note that probably IdentityDictionary needs an extra branch in the primitive, because it has proto and parent instvars.

one more thing: anything that implements == should also implement hash. This is e.g. necessary for it to work in Set, or as keys of Dictionary.

I would suggest checking the number of entries too before iterating. Also, I don't think there is a reason to iterate over both dictionary key-sets.

I puzzled over this for a minute, but it turns out it's a little deeper than that: checking the size appears to eliminate the need to iterate over both sides!

That is, the potential failure case with looping over only one side is if the other side contains an entry not present in the side you looped through -- but in that case, the sizes will be different.

@ekermit the message .keys will generate a new object (a Set of keys), so it's not optimal. Better to check directly:

== { |that|
	if(that.isKindOf(this.class).not) { ^false };
	if(that.size != this.size) { ^false };
	that.keysValuesDo { |key, val|
		if(this.at(key) != val) { ^false }
	};
	^true
}

For IdentityDictionary, we'll need:

== { |that|
	^this.superPerform('==', that) 
		and: { parent == that.parent } 
		and: { proto == that.proto } 
		and: { know == that.know }
}

I was about to report an issue with equality for Sets with objects that have a custom '==' method defined and I found this thread. The proposed solution ( #3011 ) seems to target Dictionary and its subclasses(?), whereas my issue may point to a bug in Dictionary's superclass - Set.

It might be that I going about this the wrong way in general, in which case I hope to be enlightened. Not sure if I should make this a separate issue, so I adding it to this thread. Please let me know if you want me to make it a separate issue.

I am getting unstable results comparing two Set objects containing objects of a class that defines its own equality '==' method. The results returns seemingly random true and false values.

Here is a class I use for testing:

MyClass{
	var <aa;
	var <bb;

	*new{arg aa, bb;
		^super.newCopyArgs(aa, bb);
	}

	=={arg val;
		if(val.isKindOf(this.class).not, {
			^false;
		});
		if((aa == val.aa).not, {
			^false;
		});
		if((bb == val.bb).not, {
			^false;
		});
		^true;
	}

}

// returns steady 'true' values
MyClass(11, 22) == MyClass(11,22); 
//returns steady 'true' values
[MyClass(11, 22)] == [MyClass(11,22)]; 
// returns 'true' and 'false' values arbitrarly
Set[MyClass(11, 22)] == Set[MyClass(11,22)]; 

@blacksound Your object doesn't provide a hash function so its hash (inherited from Object's default implementation) is based on identity, not equality.

Note from the docs (Object:-hash):

.hash: Answer a code used to index into a hash table. This is used by Dictionary and Set and their subclasses to implement fast object lookup. Objects which are equal == should have the same hash values. Whenever == is overridden in a class, hash should be overridden as well.

(There's a similar note on == as well)

Thanks Brian,
Would thai be a possible solution for hash method?:

hash{
    ^this.instVarHash([\aa, \bb]);
}

yes, that is the standard way to do it. Recently I noticed that the order should be encoded in instVarHash, too, but that is another issue.

@blacksound Yes, in fact you could simplify it to ^this.instVarHash; without arguments, it operates on all the instance variables. if you intend to make your == always check whether all instances variables are equal between instances, this is the clearer route. but maybe you have a cc that can be true or false and MyClass(0, 1, cc: true) == MyClass(0, 1, cc: false). Then you wouldn't want the hash function to hash cc, and you should explicitly list the instance variables you want to check. you'll have to think ahead to decide which of these is better; either option could be viewed as defensive programming, but the best solution is to have a test suite to ensure both equality and hash-equality (that a == b => a.hash == b.hash) for a relevant set of conditions.

… for equality (==), you have the corresponding compareObject method.