On Apr 25, 2010, at 6:55, Tobias C. Rittweiler wrote:
I think that's past Alan's point which, from my understanding, is simply "Java enums should be comparable by EQL." Makes perfect sense as EQL is for object identity.
FWIW, I think it makes sense to have EQL compare “deeply” anything which is a strictly (outside of using explicitly write-to-arbitrary- memory operations) immutable “box”. Such immutability is rare in CL: characters and numbers happen to be its only occurrences. But the spirit of the thing, it seems to me, is to make EQL hide distinctions which are of no use whatsoever to the end programmer.
(Note that by strictly immutable I mean that you can't change *what object the box contains*, not that you can't mutate the object the box contains if that object is mutable.)
Rather provide an EXT:EQUIVALENT generic function (or some small protocol) which can a) be extended by the user, b) hooks into however Java does it (Comparable?).
Object.equals(Object), actually.