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.