|
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)
|
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.