Request for review Daniel Ziltener (09 Mar 2026 01:24 UTC)
Re: Request for review Arthur A. Gleckler (09 Mar 2026 01:32 UTC)
Re: Request for review Peter McGoron (09 Mar 2026 01:45 UTC)
Re: Request for review jobol (09 Mar 2026 18:52 UTC)
Re: Request for review Daniel Ziltener (09 Mar 2026 22:36 UTC)
Re: Request for review Daniel Ziltener (11 Mar 2026 22:59 UTC)
Re: Request for review Daniel Ziltener (09 Mar 2026 22:39 UTC)
Re: Request for review Peter McGoron (09 Mar 2026 23:22 UTC)
Re: Request for review Daniel Ziltener (11 Mar 2026 23:12 UTC)
Re: Request for review Arthur A. Gleckler (11 Mar 2026 23:23 UTC)
Re: Request for review jobol (11 Mar 2026 21:38 UTC)
Re: Request for review Daniel Ziltener (11 Mar 2026 22:48 UTC)
Re: Request for review jobol (13 Mar 2026 07:50 UTC)
Re: Request for review John Cowan (13 Mar 2026 14:16 UTC)
Re: Request for review Daniel Ziltener (13 Mar 2026 15:00 UTC)
Re: Request for review jobol (13 Mar 2026 15:39 UTC)
Re: Request for review Daniel Ziltener (13 Mar 2026 22:43 UTC)
Re: Request for review John Cowan (14 Mar 2026 07:47 UTC)
Re: Request for review jobol (14 Mar 2026 07:54 UTC)
Re: Request for review Daniel Ziltener (15 Mar 2026 23:30 UTC)

Re: Request for review Daniel Ziltener 13 Mar 2026 15:00 UTC

So you'd suggest using clone/copy for the kind of cloning that the
library is currently doing - that is, creating a "rump object" that
refers to its parent for everything - and shallow-copy for a version
where all the slots are copied as well?

I am also not sure such an additional cloning functionality would be a
good idea, because it cannot really keep its implied promises - e.g.
value slots that point to a record will still point to the exact same
record and thus follow all changes to it, even though such a copy that
"copies all slots" would suggest otherwise.