On 3/11/26 22:37, jobol wrote:
> Hello Zilti,
>
> 1. My common understanding of 'clone' method is, with vocabulary
> of srfi 263, that slots of an object are copied into a new instance.
> Then same parents, same methods, values copied.
This is, as written in the description of the `clone` message, not correct.
> 2. The message 'clone' is probably not well named and can lead to
> confusion (see above). The semantic of its action is nearest to a kind
> 'new'. But 'new' doesn't seem to be a good choice because also of
> confusion because it often has arguments that are copied to the created
> instance. Possible other choices: derivate, instanciate, create, make.
"new" has a very different semantic; it means creating an instance of a
class. Since this is a prototype object system, there are no instances,
just classes. "Instanciate" would therefore also be a bad choice; both
suggest that there is shared structure between class and (derived)
instance. "create" and "make" suggest, IMO, that a completely new and
separate thing is created, which is not accurate either. "Self", the
language which pioneered prototype object systems, uses "copy"; I guess
I could also rename it to that. "clone" feels close enough to "copy" and
is the name used in Prometheus, so I kept that.
> 3. The message 'clone' create a single slot for its parent. What is its
> name? 'parent'? If yes, telling it would be good.
Yes, the slot is named `parent`, and that is already in the
documentation: "|Return a clone of the message recipient. This creates a
new object with a single slot, "parent", which points to the object
cloned from."|
> 4. The message 'has-ancestor' is related to immediate ancestors or to
> full ancestors?
To all ancestors of the object.
> 5. You choose 'immediate-' as opposite to 'full-' but other
> possibilities exist: 'proper-', 'direct-', 'own-', ... or just nothing.
> Is there a reason?
Yes, I kept that terminology from the prometheus object system, which
was the prior art for this SRFI.
> 6. From code:
>
>    (define-object P (*the-root-object*) (a set-a! 0))
>    (define-object C (P) (a 1))
>    (C 'set-a! 2)
>
> What are outputs of:
>
>    (C 'a)
>    ((C 'mirror) 'immediate-slot-list)
>    ((C 'mirror) 'full-slot-list)
>
> ?

(C 'a) ;=> 2
((C 'mirror) 'immediate-slot-list) ;=> ((a set-a! value) (mirror #f
method) (parent #f parent))
((C 'mirror) 'full-slot-list) ;=> ((set-method-slot! #f method)
(delete-slot! #f method) (set-value-slot! #f method) (set-parent-slot!
#f method) (message-not-understood #f method) (ambiguous-message-send #f
method) (full-slot-list #f method) (immediate-slot-list #f method)
(full-ancestor-list #f method) (immediate-ancestor-list #f method)
(immediate-message-alist #f method) (clone #f method) (mirror #f method)
(parent #f parent))

I adjusted the documentation for `set-value-slot!` to make this more
clear. That one indeed is confusing.

> 7. The message 'delete-slot!' only acts on the 'immediate' ('proper',
> 'direct', ...) instance. Is it possible to tell it in the text?

I think it is already well-reflected in the text; "Delete the slot named
'name' from the receiving object. [...] |Beware that the parents might
contain a slot of the same name, so a message send can still succeed
even after a slot is deleted"|

|If you have a suggestion for a better description for this (or one of
the other points), I'd be willing to adjust. It felt clear to me, but I
am aware that, as the one working on this SRFI and having spent a lot of
time in it, this feeling can be very misleading.|

> Regards
> José
Best regards,
Daniel Ziltener