Immutably updating objects Vladimir Nikishkin (31 Oct 2022 01:36 UTC)
|
Re: Immutably updating objects
Arthur A. Gleckler
(31 Oct 2022 03:57 UTC)
|
Re: Immutably updating objects
Marc Nieper-Wißkirchen
(31 Oct 2022 10:08 UTC)
|
Re: Immutably updating objects
siiky
(31 Oct 2022 10:18 UTC)
|
Re: Immutably updating objects
Marc Nieper-Wißkirchen
(31 Oct 2022 10:53 UTC)
|
Re: Immutably updating objects
Vladimir Nikishkin
(31 Oct 2022 12:54 UTC)
|
Re: Immutably updating objects
Marc Nieper-Wißkirchen
(31 Oct 2022 13:09 UTC)
|
Re: Immutably updating objects
Vladimir Nikishkin
(03 Nov 2022 02:12 UTC)
|
Re: Immutably updating objects
Marc Nieper-Wißkirchen
(03 Nov 2022 07:13 UTC)
|
Re: Immutably updating objects
Vladimir Nikishkin
(03 Nov 2022 08:56 UTC)
|
Re: Immutably updating objects
Marc Nieper-Wißkirchen
(03 Nov 2022 13:17 UTC)
|
I apologise in advance for a question which might be not entirely related to the "reconciliation" attempt per se, but since the "object system" of r7rs-large is being discussed here, it might be better doing it here. Would there be any benefit to having a default interface for "getting a new object which is identical to the old one, except some of the fields are different"? I can, naturally, create a new object by extracting all fields from the old one, but that's manual work, requires listing all field names, and is potentially not as efficient. It could have been a small extension to the way fields are declared, that is (field get-field set-field! get-new-object-with-updated-field), but what if I need to update several fields, in a single form evaluation? (Because I want all my objects throughout the program's lifetime to be in a consistent state.) Sorry again if this SRFI is not the best place to ask the Schemers to think about this subject. -- Yours sincerely, Vladimir Nikishkin (Sent from GMail web interface.)