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 <[email protected]> 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 <[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 > -- Jonathan "Duke" Leto [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
