In CLOS, instance remorphing considered useless in practice?

[Pascal Costanza]

> On 9 Dec 2020, at 10:11, Jean-Claude Beaudoin <jean.claude.beaudoin at gmail.com> wrote:
> 
> 
> 
> On Wed, Dec 9, 2020 at 3:16 AM Nick Levine <nick at nicklevine.org <mailto:nick at nicklevine.org>> wrote:
> > Can I ask why you invoke #'CL:CHANGE-CLASS on an object instead of simply creating a new instance of the second class with adequate initialization?
> 
> Because you’d have to go find all the pointers to the old instance. Maybe you don’t want to do that. Or maybe you don’t care, but that’s ok because what CLOS gives you is possibilities. 
> 
> Yes, preserving instance identity is at the core of the question. It could even be the only question here. Is there any other?
> 
> But what looks like an occasional convenience comes at a cost.

The cost of implementing the mechanisms involved has already been payed. Changing the semantics would imply changing the implementations, and would have an impact on all existing libraries and applications. So you would be incurring an additional cost. (That alone is not a good argument for keeping the feature, it’s just to remind you that the cost/benefit analysis in this regard is not straightforward.)

I doubt that the cost in terms of runtime performance really matters that much in practice. Class redefinitions are rare, I suppose, and I doubt that slot accesses have a high overhead because of them. (I would think that unbound slots, for example, cost more, but that’s just guessing.)

In my experience, the two most important feature for improving performance in Common Lisp are inlining and stack allocation. If you could work on a way how to inline generic functions while maintaining the ability to add and remove methods at runtime, and to make dynamic-extent declarations on CLOS instances effective, that would probably buy us a lot more in terms of performance than restricting class redefinition capabilities.


Pascal

--
Pascal Costanza


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201209/04772394/attachment.html>