[armedbear-devel] eql for java objects

[Alessio Stalla]

On Sun, Apr 25, 2010 at 8:37 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
> Hi all,
>
> On Sun, Apr 25, 2010 at 7:26 PM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>>
>> On Apr 25, 2010, at 6:55 AM, 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.
>>
>> Yes, and Java "objects" too.
>
> I've read this thread, the thread on c.l.l regarding EQUAL and the
> definitions of EQ and EQL. The following is my interpretation of it
> all:
>
> 1. Our Java side JavaObject class is merely a box for a Java instance
> value (a pointer to a Java object, if you will)
> 2. The definitions of EQ and EQL talk about Objects, but I interpret
> them to refer to the first meaning in [1], not to instances of lisp
> classes
> 3. Our JavaObjects have not been defined in the (Common) Lisp spec;
> they don't adhere to the object-instantiation protocol nor are they
> any of any one of the predefined built-in classes and therefore can't
> be taken to be "Lisp Objects" in that sense of the word
> 4. From point (1) and the definitions of EQ and EQL, I concur with
> Alan that "raison d'etre" of EQL should equally apply to JavaObjects
> 5. From ponits (2) and (3) and the discussion on #lisp and c.l.l, I
> conclude that we're basically free to extend the meaning of EQL here:
> the JavaObject values were not in the spec to begin with: they're not
> Lisp class instances, they're not symbols, numbers nor characters
>
> The only objection there is from both #lisp and c.l.l is that EQ, EQL
> and EQUAL shouldn't start to behave unpredictably regarding defined
> behaviour. For all the spec cares, we would have generated an error
> when EQ-comparing 2 java objects...
>
>
> Agreed?

I agree almost completely, but I'd like to add that:

1. if EQL is modified, then EQUAL must be modified as well because
(eql x y) should always imply (equal x y)
2. if we have freedom to modify EQL and EQUAL, then I'd say that EQUAL
should call Object.equals(), but I know this is controversial
3. in any case, hash functions must be modified as well to respect the
behavior of EQL and EQUAL.

What do you think?

-- Alessio