On 25 April 2010 21:37, Erik Huelsmann ehuels@gmail.com wrote:
- Our Java side JavaObject class is merely a box for a Java instance
value (a pointer to a Java object, if you will)
The abstract boxing is an implementation detail. If you want to walk through that implementation detail in order to find out whether there are java enums underneath the boxing, CLHS won't stop you.
- 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
Objects in this case are not object-oriented in any way; multiple languages, object-oriented or not, have a term object that means an addressable thing that may have multiple references (in the case of lisp, dynamic and lexical) to it. As far as I can see, Common Lisp is not at all different in this regard. Numbers are objects. Sequences are objects. CLOS objects are objects.
- 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
I do believe that it's within the CL spec to do EQL to JavaObjects wrapping enums/ints so that the values are inspected, and as java-reference comparison to others. Some JavaObjects are numbers. Some are not.