[armedbear-devel] eql for java objects

[Erik Huelsmann]

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?

Bye,


Erik.


[1] http://www.lispworks.com/documentation/lw51/CLHS/Body/26_glo_o.htm#object