[armedbear-devel] eql for java objects

Tobias C. Rittweiler tcr at freebits.de
Sun Apr 25 20:36:45 UTC 2010

Alessio Stalla <alessiostalla at gmail.com>

> > No that would be false reasoning IMHO. The only reason why it's
> > acceptable to extend EQL that way is because the Notes section in EQL
> > kind of implies (albeit does not spell it out explicitly) certain
> > implementational freedom in the interplay of EQ and EQL.
> I don't read more implementational freedom in EQL than in EQUAL.
> For EQL, the precise rules are:
> "The value of eql is true of two objects, x and y, in the folowing (sic) cases:
> 1. If x and y are eq.
> 2. If x and y are both numbers of the same type and the same value.
> 3. If they are both characters that represent the same character.
> Otherwise the value of eql is false."
> The notes then say a more general thing, that "eql tells whether two
> objects are conceptually the same, whereas eq tells whether two
> objects are implementationally identical".
> For EQUAL, instead:
> "Returns true if x and y are structurally similar (isomorphic)
> objects" describes it in general, as EQL is described in general in
> its notes.

The notes section of EQL is not interesting because of the "conceptually
the same" -- that's too vague and could mean anything anway; the crux is
the implied distinction between EQL and EQ, and telling them apart by
stating that EQ is inherently implementation-dependent whereas EQL is
supposed to smooth over implementational quirks.


More information about the armedbear-devel mailing list