From: Tomas Zellerin <zellerin@gm...> - 2006-07-24 13:00:09
I am not sure whether this is sctrictly speaking a clhs non-conformance or not:
The clisp describe code appears to add text "foo is" to the
description on its own, before calling describe-object. This makes
example in description of describe-object
in CLHS produce undesired output - the text "#<FEDERATION-STARSHIP
#x19F62D11> is" is produced twice.
The clhs says on describe "The actual act of describing the object is
implemented by describe-object. describe exists as an interface
primarily to manage argument defaulting (including conversion of
arguments t and nil into stream objects) and to inhibit any return
values from describe-object.", but it does not explicitly prohibit
describe to do more.
Is there a reason for this behaviour? It makes writing good-looking
portable descriptions of objects more complicated.
From: Tomas Zellerin <zellerin@gm...> - 2006-07-24 14:35:41
On 7/24/06, Sam Steingold <sds@...> wrote:
> > * Tomas Zellerin <mryyreva@...> [2006-07-24 15:00:03 +0200]:
> > Is there a reason for this behaviour?
> since describe output always starts with "~S is ", it makes sense to do
> that at the highest level.
This is certainly true for objects described by the implementation.
However, the describe-object is also meant as hook for users:
"Users can write methods for describe-object for their own classes if
they do not wish to inherit an implementation-supplied method."
and here the details of the API do matter. Other implementation seem
to do as hinted in CLHS.
I can live easily with it as it is now; I was just curious whether to
#-clisp the "~S is" string in describe-object or to expect change.