in reply to deep_copy objects question

Notice that Randal's code supports copying only structures composed of arrays and hashes. You really do not want to break object abstractions by copying their guts - it is bound to lead to problems sooner or later. Anyway, in the most general sense, you cannot always correctly copy objects, handles, code, etc.

Code is a problem, since there may be persistent state associated with it - how do you duplicate it? Handles almost always have state that cannot be duplicated to an independent copy.

Even if you assume that your structure does not contain anything but pure Perl objects, those object can contain references to code and handles. Moreover, the class implementations for the objects may be keeping class-wide state, which means the only valid way of copying the object implementation (from the class point of view) is to use a class-specific copy constructor, if the class allows this by implementing one.

This, of course, does not disagree with the other posters' suggestions - you can always take the risk and just deep-copy and re-bless anything you find. Just watch out for the consequences.

Replies are listed 'Best First'.
•Re^2: deep_copy objects question
by merlyn (Sage) on Aug 13, 2004 at 20:54 UTC
Re^2: deep_copy objects question
by JAMBOID (Sexton) on Aug 13, 2004 at 20:16 UTC
    Thanks for the wisdom.
    I recoded to not require copying but hold onto the original references. But if I need to copy objects I'll use Clone or Storeable.
    Peace and a veritable lack of bugs.
    --jambo