Overloading the assignment operator, right now!

[Bruno Medeiros]

pragma wrote:
> Hasan Aljudy wrote:
>>
>> I vote:
>> No for copy operators.
>> Specially no for the ugly and cumbersome-to-type := operator.
>>
>> Yes for auto-generated copy methods/properties. (both deep and shallow)
>>
>> T x = b.dup.deep;
>> T y = b.dup.shallow;
> 
> The only problem with this is that you can't have a compiler-generated 
> deep copy without taking on some serious consequences and/or risks. IMO, 
> that's too much effort for a compiler author, for a feature that is so 
> limited in use and scope.
> 

I don't think you cave have a compiler-generated deep copy, *at all*. At 
least for the proper notion of "deep copy".
When one speaks of a clone method, or of a "deep copy", what one means 
(or at least *should* mean), is a copy of the "abstract state" of the 
object. A *conceptual* copy of the the object.

Such "abstract state" might not coincide with the set of *all* 
objects/members that can be reached recursively from the target object. 
There might be members that are simply not part of the object's abstract 
state.
For example, consider some GUI Button widget class that has a member 
which is a reference to it's parent widget. If I want to clone/deep-copy 
this Button widget, should it clone it's parent widget too, and possibly 
the whole encompassing window?
Similar example: a Shape class, which would have a list of vertexes, 
color, position and a reference to a Renderer which is used for drawing. 
When a Shape is cloned, should all members be cloned, in particular the 
Renderer member as well? Likely not, because it is not part of the 
abstract state of Shape.

This notion of abstract state was actually picked up in that paper about 
Javari (immutability for Java), as some might have noticed. ;)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D