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. 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. 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. Yours aye Svante Jean-Claude Beaudoin writes: > Hello Pros of Common Lisp, > > Here is my attempt at starting a significant (and hopefully useful) debate > on a subject squarely about Common Lisp and its internals. > > My main stance here is to state that I have yet to see, in a significant > application, any use of functions #'cl:make-instance-obsolete and > #'cl:update-instance-for-redefined-class and of the underlying machinery > that support the remorphing of instances following a class redefinition > (through a subsequent cl:defclass most likely). I can state the same thing > about #'cl:update-instance-for-different-class and #'cl:change-class. > > The machinery required of any CL implementation to properly support those > functions (mentioned here above) is quite significant in its complexity and > usually imposes a sizeable performance penalty on the speed of any instance > slot access. > > A different choice of class redefinition semantics can lead to an > implementation of CLOS with much reduced instance slot access overhead. > > The necessity of supporting instance remorphing should therefore be well > motivated by very significant gains in application code performance (in > speed and/or size and/or expressiveness power). > > Can anyone of you point me to some evidence of such application level > usefulness? > Is there any notorious usecase of this (instance remorphing) since its > inclusion into ANSI CL? > > > By the way, at the bottom of the entry about #'cl:change-class in the text > of the CL standard, one can find a "Notes:" section that starts with this > sentence: "The generic function change-class has several semantic > difficulties." And this was written in the context of a single-threaded > implementation, as ANSI-CL limited itself. I bet that almost all currently > significant CL implementations are now multi-threaded, therefore the > "several semantic difficulties" are greatly and gravely compounded. In my > opinion, this makes proper motivation of usefulness all the more imperious. > What do you think?
