[chuck-users] implementing a set (was object / class hacking)

[Kassen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090930/169d9f71/attachment.htm>