Re: GOOPS functional setter

[tomas@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Jan 13, 2017 at 08:11:28PM -0600, Christopher Allan Webber wrote:
> 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.
> Clone makes it sound the same, but the goal is change without affecting
> the original.  It's attempting to be the same as slot-set! but
> functional, hence slot-fset.  Again, inspired by set-field and
> set-fields from (srfi srfi-9 gnu).

Yes, and after having read your post I understood where you came from.
The naming wouldn't have been discovrable for me right off.

Curiously, Jan (also in this thread) came up with "clone",
independently.

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.

> However, I'm open to another name, if someone has something better...

At the end it's not that important: you made the function, you name
it :)

If my questions elicit some resonance in you, then they might be
useful.

> (Also, it would even be nicer if it were possible to make the new
> instance without copying every field manually as I did here.  It would
> be interesting if there were a metaclass that was smarter about slot
> allocation and used some functional structure so that we didn't need to
> iterate through every field just to change the one slot.  I'm not sure
> how hard that would be to do, or if it would be of significant benefit
> in the end.)

That's the more important part: the *interface* makes those things
possible in the first place (whether by a more efficient clone
primitive, as you envision, or by a clever compiler or both). Thus
a Good Thing, regardless of its name :)

thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlh5+KcACgkQBcgs9XrR2kaDDACcDLOi8W1gS9TZ0oU4w1bxswAU
OgUAn0HAN1krKDEhJads7v9nIrq7mXRg
=7b9N
-----END PGP SIGNATURE-----