public inbox for
 help / color / mirror / Atom feed
* Rationale for providing "equal?"-like "equals" method for gnu.lists.Pair
@ 2022-01-05  8:00 Panicz Maciej Godek
  0 siblings, 0 replies; only message in thread
From: Panicz Maciej Godek @ 2022-01-05  8:00 UTC (permalink / raw)
  To: kawa

I'd like to know what the rationale for providing the "equals" method with
"structural identity" is.

I found it problematic in at least one respect: I have decided to use
Java's weak hash tables to represent "properties" attached to cons-cells.
However, since those hash tables rely on the Object's "equals" method, the
table is unable to distinguish between two different cons-cells that point
to the same object.

I came up with two solutions to this problem. The first one was patching
the implementation of Pair, simply by removing the implementations of the
equals method is LList and its subclasses. (IIRC there were some failing
tests after the change, but I didn't investigate further)

The second solution was simply subclassing gnu.lists.Pair and overriding
its equals and hashCode methods, as I did here:

It works, but the "equal?" semantics for cons-cells doesn't seem right to
me, so I wonder what was the reason for providing it, and whether there is
some code which relies on it

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-01-05  8:00 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-05  8:00 Rationale for providing "equal?"-like "equals" method for gnu.lists.Pair Panicz Maciej Godek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).