On Tue, Dec 8, 2020 at 4:17 PM Svante Carl v. Erichsen < [email protected]> 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
