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.