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)

Immutably updating objects Vladimir Nikishkin 31 Oct 2022 01:35 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.)