[Openmcl-devel] defstruct - generic constructor?

[Hans Hübner]

David,

On Thu, Apr 30, 2009 at 00:05, David Reitter <reitter at cmu.edu> wrote:
> Dan Weinreb:
>> This behavior isn't specific to CCL; it's part of the definition
>> of Common Lisp.  If you want to use make-instance, you
>> should use defclass instead of defstruct.  (defstruct is an
>> earlier, more primitive facility that was added to Lisp
>> before object-oriented programming.)
>
> Another good idea; I'll definitely consider doing that, with a macro
> to allow users of my API to define their classes using an interface
> that is as simple as defstruct.

If what you are looking for is a simplified DEFCLASS macro, you could
as well use one of those that have already been written, like
http://common-lisp.net/project/defclass-star/ - When I started
programming in Lisp, I used something like that, too, and I also
thought it would be a good idea to force users of my libraries use
that improved DEFCLASS as well.  After a few years, I recognized that
this actually was a bad idea.  Each of these convenience macros either
is less powerful and supports fewer options than DEFCLASS (making it
painful to use for advanced users) or ends up being as complicated as
DEFCLASS (but being un- or underdocumented).

DEFCLASS is repetetive and verbose, but I have come to appreciate its
flexibility.  It also has the distinct advantage of being transparent,
which is very valuable.  Transparency here means that all symbols that
the class definitions are visible in the DEFCLASS invocation.  It does
not create new symbols, and only uses a very restricted number of
symbols (:metaclass STANDARD-CLASS comes to mind, but there may be a
select few more).  As a general rule, transparent macros are easier to
work with than those that create other symbols (like accessors,
constructors) underneath.

Partly, non-transparency would be easier to deal with using an
advanced IDE that can intelligently expand macros.  I am not aware of
such an IDE, thus I am recommending to keep things simple to work with
using the commonly used inferior tools.

> It seems that there are much better facilities for introspection
> available for classes than for structures.

CLOS classes also can be defined and changed on the fly, as per
definition.  You can change the class of an object and you can change
the class itself, both in a well-defined way and at run (development)
time.  No such guarantees are made for structures, and this can be
very annoying when you're working with a large in-memory data set and
discover that you need to, say, add a structure field.

Convenience is the best reason to use structs, but the drawbacks are
considerable.  For new libraries that are supposed to be used by
others, use CLOS, and stick to the standard facilities provided by
CLOS when specifying the interface.  If you want to use convenience
macros to make DEFCLASS look nicer, use them only within your own
application code, not in libraries that you indend to share.

-Hans