Re: meta information about structure types

[Bruno H. <br...@cl...>]

Hi Sam,

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

This is the good principle if
  - the various types fit into a common scheme,
  - the functions have the same kind of input and the same kind of output.

In this case, the two types are neither sub- nor supertype, and the
inputs are not the same objects (classes in one case, symbols in the other).

Also the common portion of the API is just two functions: -direct-slots
and -instance-size. The non-overlap is bigger than the overlap in the
diagram.

> > 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.

kconstructors yes. copiers no: the notion of copying an object by copying
slots does not work for complex objects; there you need the
INITIALIZE-INSTANCE and MAKE-LOAD-FORM generics.

> 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.

No I'm not forcing users to do this. The MOP, not clisp, specifies the
class-* methods to take a class object, not a symbol. Actually I'd say
the programmer who wants to go from a symbol to a direct-slots list directly
has not understood what a class is about. The class is the essential entity
here. The symbol is just its name.

> > 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.

For interactive functions, this may be a good approach. For APIs, it's
a sin to add "useful behaviour" to some functions and not to others:
For APIs, orthogonality is more important.

> 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.

No, with my approach there will be two functions: class-direct-slots,
taking a class object, and structure-direct-slots, taking a symbol.

The user calls either
    (class-direct-slots (find-class name))
or
    (structure-direct-slots name)

depending on what he wants.

Bruno