[armedbear-devel] eql for java objects

[Alan Ruttenberg]

On Sun, Apr 25, 2010 at 4:50 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Sun, Apr 25, 2010 at 10:25 PM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> On Sun, Apr 25, 2010 at 4:05 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
>>> On Sun, Apr 25, 2010 at 9:49 PM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
>>>> Alessio Stalla <alessiostalla at gmail.com>
>>>> writes:
>>>>
>>>>> 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:
>>>>>>>
>>
>> My read is that == on the java side is eql on the lisp side, that
>> equals on the java side is it's own thing, and that we would be on the
>> right side to define lisp equal and equalp on java objects such as
>> arraylists in such a way that the comparison is elementwise as would
>> be done on the lisp side.
>
> Ok, I understand your view. However, if you fear equals() is too much
> of a black box, and might make cl:equal work in unexpected ways, then
> I'd prefer always using ==. Traversing stuff in Lisp isn't wise imho,
> since collections are not just ArrayLists and LinkedLists, but also
> Sets (for which you need another algorithm than traversing it one
> element at a time, since sets are unordered in general), and more
> hairy things like PersistentCollection (Hibernate) which potentially
> are not easily compared elementwise. equals() exists also to provide
> an unified entry point for all those diverse algorithms.

Again, I'm not too bent one way or another about equals. I agree in
general that it is complicated and my tendency would be to try to make
only those data structures on the java side that have cognates on the
lisp side respond to equals in the same way as their cognates.

-Alan


>
> Alessio
>