In CLOS, instance remorphing considered useless in practice?

[Zach Beane]

I see it and use it a lot. Maybe that's not significant to you, but it's
significant to me.

Zach

On Tue, Dec 8, 2020 at 2:51 PM Jean-Claude Beaudoin <
jean.claude.beaudoin at gmail.com> wrote:

>
> 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?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201208/1eb6fe1e/attachment.html>