[RFC] clone semantics

[Allison Randal]

On 3/11/10 7:11 PM, Peter Lobsinger wrote:
>
> While I want the ability to do both deep and shallow clones, I think
> the responsibility for deep cloning is not something we want to push
> into PMCs if we don't have to. TT #1015 is caused by Hash PMC not
> being able to handle that responsibility.

This is a similar issue to the old method of creating Array/Hash 
iterators, the current strategy is just too promiscuous with the 
internals of the item it's traversing.

> The three visitor API PMCs that have already been created (ImageIO and
> ImageIOSize from trunk, VisitClone from tt1015 branch), use a hash
> (called 'seen') to keep track of this for PMCs, so can store arbitrary
> information about already visited elements.
>
> Eliminating duplicate STRING buffers is not something that is being
> done ATM, but would probably be fairly easy to add. AFAIK, you cannot
> communicate between components at a PIR/HLL level by modifying a
> shared string buffer because these are COW / immutable. So this would
> only be an optimization, not a functionality change.
>
> freeze/thaw/visit already take a parameter for the registry: PMC *info
> (also known as visit_info, visit).

+1

> These PMCs are expected to provide a certain vtable-based API (I
> should document that somewhere)

Yes, please write up briefly for PDD 17, and pass the patch around the 
list for review.

> but are free to provide that as they
> see fit. For example, freezing and cloning traversals can keep their
> state in a "seen" hash; marking traversal (which probably shouldn't
> allocate while traversing, but is hopefully unique per-interpreter at
> a given time) might keep its state in PObj flags.

To be clear, the "seen" hash is stored as an attribute of the VisitClone 
PMC? And each deep-cloning process is a unique instance of the 
VisitClone PMC, in much the same way that each iterator is a unique 
instance of HashIterator/ArrayIterator?

Allison