[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: immutability and ==



>>>>> "Jonathan" == Jonathan Hseu <vomjom@vomjom.org> writes:

    > Following previous discussion of immutability and ==: If ==
    > returns true for equivalent immutable objects, then there should
    > be a way to specify classes (or properties?) as immutable.
    > Overriding == for <tup> and <str> won't be enough.  Also, if a
    > programmer makes immutable objects, then they will have to
    > remember to override == every time...  which might become a
    > pain.

yes, being able to add immutable properties would be quite useful. and
as Baker points out, most of the time you can get away with not
defining an equality predicate for your classes; just compare objects
according to the contents of their slots. only when you have mutable
slots does an equality predicate become necessary, i think.

    > If they forget, unexpected behavior will occur for anyone that
    > uses their code.

right: the point of having a mutability model is to reduce surprises :)

    > On the subject, I had a bug in my code recently because of
    > unexpected behavior: Let's say I have a vector called 'test'.
    > If I (as <vec> test), it will return the same object.  If I (as
    > <lst> test), it will return a new object.

    > If I _always_ want a new object, then I have to (dup) it.  It
    > seems somewhat wasteful to create two new copies in the second
    > case...

    > Plus, an unsuspecting programmer may use (as) believing it will
    > always return a new object.

    > My opinion is: (as) should always return a new object.
    > Thoughts?

I'd say your expectations aren't taking into account the difference
between mutable and immutable objects :) I'd say that if you want to
write non-destructive code, it should operate on immutable
objects. Furthermore, it seems to me that no function should
implicitly copy -- i.e., if one is operating on mutable data structures, it
makes sense to only copy them on request; if one is operating on
immutable data structure, "copy" isn't defined for it since it should
be compared for structural equality only, not pointer comparison.

Allen

Attachment: pgp03639.pgp
Description: PGP signature