On Tue, Dec 8, 2020 at 4:17 PM Svante Carl v. Erichsen <svante.v.erichsen@web.de> wrote:
Hi!

It is used all the time while working on a live system (image).

If you want raw performance, you can often substitute structs, if you
can live with the downsides: all objects from a class must be thrown
away on redefinition (which might be OK if you want to treat e. g. a
production system as unchangeable except through re-deployment), you
only get single inheritance (which is often not needed anyway), and most
of the MOP goodness is gone, starting with that you can't have a
different metaclass than structure-class.  Also, because of the
mentioned inflexibility, you have to dismiss several warnings if you do
re-define a struct.

On the other hand, structs have a lot of other, more low-level
convenience tooling, e. g. automatic and portable serialization and
deserialization.

I _think_ that one might be able to create a new macro (let's say
def-struct-class) that has exactly the same semantics as defstruct, but
in development mode uses defclass underneath, while being an alias for
defstruct in production mode.  It might get a bit hairy to adhere to
:type :list or :vector, though.  The result is a bit limited, but just
might be what you need.

Yep. Got that.


The folk at ITA also did quite some work on compile-time metaprogramming
in order to get fast objects etc., so maybe they can chime in.

This tells me that ITA had a pretty big itch to scratch in that area. Very interesting clue...


Anyway, my stance is that the incredibly flexible MOP classes provide
general semantic usefulness, but Common Lisp does offer more constrained
options that trade general usefulness for speed.

I agree with one caveat, in this area ANSI-CL pretty gratuitously went one notch too far I'd say.

Regards,

Jean-Claude