I would like to momentarily return to a previous issue.<br><br>Before I said that the "==" operator doesn't cover identity in this sense; I was wrong and it does partially.<br><br>consider;<br><br>========<br>
Gain foo;<br>foo @=> Gain bar;<br><br>//should be true<br>if (foo == foo) <<<"true">>>;<br>else <<<"false">>>;<br><br>//also true<br>if (foo == bar) <<<"true">>>;<br>
else <<<"false">>>;<br>============<br><br>As compared to;<br>=========<br><br>baz foo;<br>foo @=> baz bar;<br>//will lead to a error as "==" isn't overloaded to extend to this<br>
if (foo == foo) <<<"true">>>;<br>else <<<"false">>>;<br><br>class baz<br> {<br> int member;<br> }<br>==========<br><br>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;<br>
<br>==========<br>baz foo;<br>foo @=> baz bar;<br>//this will yield a error at the casting<br>if (( foo $ Object) == ( bar $ Object)) <<<"true">>>;<br>else <<<"false">>>;<br>
<br><br>class baz<br> {<br> int member;<br> }<br>=================<br><br>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.<br>
<br>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.<br>
<br>Yours,<br>Kas.<br>