[RFC] clone semantics

Jonathan Leto jaleto at gmail.com
Thu Mar 11 15:30:54 UTC 2010


Howdy,

+1 to "clone be made explicitly shallow, and a deep cloning op and/or
PMC can be provided."

Duke

On Thu, Mar 11, 2010 at 7:01 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> Explicitly having two types of clones for deep and shallow versions
> sounds very attractive to me. Picking only one or the other is
> obviously going to create disadvantages for people who need the other
> version. Obviously I think having only one clone op and inconsistently
> making it shallow sometimes and deep other times is the worst
> scenario.
>
> Having the existing clone op and clone VTABLE do shallow clones by
> default, and including a deep-cloning mechanism such as a new PMC for
> the purpose sounds like a good solution to me. I would love to hear
> other people's feedback on the issue, however.
>
> --Andrew Whitworth
>
>
>
> On Wed, Mar 10, 2010 at 10:11 PM, Peter Lobsinger <plobsing at gmail.com> wrote:
>> Hi,
>>
>> I've been working on TT #1015 (clone_p_p segfaults with
>> self-referential Hash pmc).
>>
>> The problem of what the clone vtable/opcode actually means has come
>> up. We have a test in t/pmc/iterator.pmc that asserts that clone is
>> shallow (the clone iterates over the same array). Meanwhile,
>> docs/book/pir/ch04_variables.pod says that clone is deep (no changes
>> to the original affect the clone).
>>
>> Both have desirable properties and are sometimes appropriate, but we
>> must be consistent in what we mean when we call clone.
>>
>> Deep clone can be built out of shallow clone and visit. AFAICT,
>> shallow clone cannot be built out of deep clone easily or efficiently.
>> Beyond shallow vs. deep cloning, given shallow clone + visit, one
>> could implement a clone with an arbitrary policy (eg: don't clone
>> classes, don't clone subs, don't clone iterator's arrays, only clone
>> 42 levels deep, etc).
>>
>> Therefore, I propose that clone be made explicitly shallow, and a deep
>> cloning op and/or PMC can be provided. TT #1015 can then easily be
>> closed by making hash clone non-recursive.
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net


More information about the parrot-dev mailing list