Re: meta information about structure types

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2005-01-25 12:01:06 +0100]:
>
> The access to copier, boa constructor and predicate names is well
> done.

thanks.

> Thanks also for introducing the symbolic constants for
> *defstruct-description-...-location*. I should have done this earlier.

indeed.  I actually wondered why you didn't do that right away and
searched for some misty* reason :-)

> Still I will make one change: instead of overloading the accessors
> class-direct-slots, class-instance-size, I will separate these into
> different functions structure-direct-slots, structure-instance-size,
> structure-kconstructors, structure-copier etc.

this violates the general principle "few functions which operate on many
types".

> The reason is 1. that the MOP API and your new API are neither a
> subset nor a superset - the MOP covers all kinds of classes but not
> LIST/VECTOR structures, and the structure API doesn't cover all kinds
> of metaclasses -, and

I see no reason in principle for CLOS classes not to have kconstructors
and copiers.

> 2. that the MOP API is based on a class object,
> whereas the structure API is based on a symbol.

that's what generic functions are for.

> Thus the structure API is better viewed as a layer partially on top of
> the MOP API, in block diagram:
>
>                             +--------------+
>                             |   Structure  |
>                             |      API     |
>                     +--------------+       |
>                     |      MOP     |       |
>                     |      API     |       |
>                     |              |       |
>                     +--------------+-------+
>
> Therefore it seems better to me to keep these APIs separate.

whatever they have in common should be kept common.
you are just forcing your users (CLOCC/PORT/mop.lisp &c)
to write

(without-package-lock ("CLOS")
(defmethod class-direct-slots ((s symbol))
  ...))

this is just not nice to your users.

> 3. The user might be surprised if by calling
>      (clos:class-direct-slots xyz),
> where xyz does not name a class, he gets a result not related to classes.

if xyz names a struct, it cannot name a class anyway, so the choice here
is between an error and a useful behavior.
I would always take some useful behavior over an error.

with my approach:
to get the behavior you want,
the user can write
(or (find-class 'xyz)
    (clos:class-direct-slots xyz))

with your approach:
to get the behavior I want,
the user has to write a much more complicated
(and less portable!)
kludge above.


[*] german and english "mist"s are both appropriate here :-)

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
A year spent in artificial intelligence is enough to make one believe in God.