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 <[email protected]> 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
