[armedbear-devel] eql for java objects

[Tobias C. Rittweiler]

Alessio Stalla <alessiostalla at gmail.com>
writes:

> On Sun, Apr 25, 2010 at 10:17 AM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> (eql (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle")
>> (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle"))
>> ->
>> NIL
>> I think it should be eql, probably eq.
>> I know they are equal.
>>
>> The documentation for eq says:
>> Returns true if its arguments are the same, identical object;
>> otherwise, returns false.
>>
>> They are and they are not. That they are not is only a quirk of the
>> implementation.
>
> Well, eq is supposed to work following "quirks of the implementation",
> for example, eql fixnums are not required to be eq and indeed they are
> not on abcl due to boxing. So two boxed java objects are not eq.
>
>> eql adds equality for characters and numbers
>
> right, and equal should provide equality for compound objects,
> descending their structure. But the standard explicitly says that
> equal behaves like eq for all objects excepts for those types
> mentioned in the definition of equal. I encountered this problem too
> in the past and I tried to understand it better by carefully reading
> the Hyperspec and by asking people on comp.lang.lisp about it. It
> seems that there's not a uniform opinion in the Lisp community: some
> say that the standard prohibits implementations from giving EQUAL a
> new meaning for "non-CL" objects. Others say that implementation can
> and sometimes should change CL functions giving them new meanings for
> implementation-specific objects. Others still say that implementations
> can extend EQUAL, but should not do it to avoid surprising the users.
> I personally think that position #2 is the most sensible in this case,
> but it's hard to get it right, because some people think #2 and #3
> break CL conformance.

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.

Regarding extending EQUAL, just don't. Whatever you do, it won't come
off as natural. 

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?).

  -T.