I would like to momentarily return to a previous issue. Before I said that the "==" operator doesn't cover identity in this sense; I was wrong and it does partially. consider; ======== Gain foo; foo @=> Gain bar; //should be true if (foo == foo) <<<"true">>>; else <<<"false">>>; //also true if (foo == bar) <<<"true">>>; else <<<"false">>>; ============ As compared to; ========= baz foo; foo @=> baz bar; //will lead to a error as "==" isn't overloaded to extend to this if (foo == foo) <<<"true">>>; else <<<"false">>>; class baz { int member; } ========== Now let's get tricky and try to write around the lack of overloading as at the testing stage we don't actually need the type; ========== baz foo; foo @=> baz bar; //this will yield a error at the casting if (( foo $ Object) == ( bar $ Object)) <<<"true">>>; else <<<"false">>>; class baz { int member; } ================= I believe this error to be another bug or omission in the type system. As a "baz" is clearly a object we should be able to cast it to Object. Because of this we won't -currently- be able to test for identity in trying to clean our array/set of identical objects. Of course we might still give a custom class a unique "id-tag" and test based on that. Unless somebody explains why and how I'm wrong in expecting the cast operator to extend to this usage I'm going to file this as a bug to the wiki. Personally I also feel that "(foo == bar)" should return true iff "(( foo $ Object) == ( bar $ Object)) " returns true and that the "==" operator should be overloaded to cover that. There might be implications to that that but currently that seems to me like the way to go; casting is fun but not *that* much fun. Yours, Kas.