Challenge supporting custom deepcopy with inheritance

[Scott David Daniels]

Michael H. Goldwasser wrote:
> On Monday June 1, 2009, Scott David Daniels wrote: 
> 
>>    Michael H. Goldwasser wrote:
>>    >   ....  I'll accept the "small price for flexibility" that you
>>    >   note, if necessary. However, I still desire a cleaner solution.
>>    
>>    You seem to think that "deepcopy" is a well-defined concept. ....
> 
>   It is clear from my original statement of the question that there is
>   a need for classes to be able to customize their own semantics for
>   supporting the deepcopy function.  That is why the deepcopy function
>   looks for a __deepcopy__ method within a class as a hook.
> 
>   My concern involves the challenge of providing a valid
>   implementation for __deepcopy__ at one level of inheritance without
>   being overly dependent on the internal mechanism used by ancestor
>   classes in supporting deepcopy.  I don't see how your comments
>   address that question.

I only meant to say, if you are looking for something neater,
consider whether there is such a thing.  Issues with deepcopy
may be (and I suspect are) inherently messy.  Further,
inheritance usually provides (in practice) a "built from"
relationship, not an "is a" relationship.  "Liskov
Substitutability," is a design goal, honored except in corner
cases and where inconvenient.

--Scott David Daniels
Scott.Daniels at Acm.Org