tomas@tuxteam.de writes:
> [fset vs clone]
>
>> I think cloning isn't as clear; what we want is something that's the
>> same as the previous instance of the object, but with one field changed.

> Yes, and after having read your post I understood where you came from.
> The naming wouldn't have been discovrable for me right off.
…
> Now I'm not trying to imply that "clone" is "more right"; actually
> I believe that there are two "modes" at work here. Let me speculate
> a bit:
>
> Perhaps from the more "strictly functional" point of view, the clone
> operation is less important, because, whether the thing is cloned
> behind the scenes or things are arranged by deep compiler magic and
> the clone doesn't happen after all is none of our business. Not the
> cloning is important, but the changed fields. In this world, the
> mutating counterpart (set) doesn't even exists. Clone wouldn't be
> an appropriate name here.
>
> - From the more "naive", "imperative" point of view, it's the clone
> operation what keeps us awake: allocating memory and things. Here
> "clone" is the right word, it seems.
>
> Perhaps what irritates me most is that "fset" is named  after
> an imperative operation (set) and lives in a functional world.
> Or something.

If I did not need a short name, I’d use something like
slot-copy-with-changed. I had an immutable datatype in Python where I
used something equivalent to

(changed event
  #:<slot-to-change> new-value
  #:<other-slot-to-change> other-new-value)

I know that this does not provide a better name by itself, but I hope it
helps finding one.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken