NICE Eiffel Standards Group -- Library Committee Mailing List To post to list: NICE-ESG-Libs@atlanta.twr.com To send mail to the Chairman of the committee: NICE-ESG-Libs-chair@atlanta.twr.com Administrative matters (sign up, unsubscribe, mail problems, etc): NICE-ESG-Libs-request@atlanta.twr.com
Date: Thu, 20 Apr 95 13:39:03 EDT From: fhart@atlanta.twr.com (C. Frederick Hart) Subject: NICE-ESG-Libs Digest V1 #211 To: NICE-ESG-Libs | By the way, if there is a frozen `standard_clone', is it really | necessary to freeze `clone'? If they are both frozen, why do they | have different description comments -- are they not synonyms forever? No, they are not precisely synonyms since their postconditions are different. standard_clone's postcondition calls standard_copy, whereas clone's postcondition calls copy. copy is redefinable so in essence clone's behavior is redefinable via copy. | 1. "Just allocate space and call `copy'": | | clone(other: GENERAL): like other is | do | !!Result; | Result.copy(other); | end; | | 2. "Allocate space, do bitwise copy, and call `copy'": | | clone(other: GENERAL): like other is | do | Result := C_function_to_malloc_and_bcopy(other); | Result.copy(other); | end; | | The problem with Alg. 1 is that "!!Result" does not ensure the class | invariant (since it does not call a creation routine), so | "Result.copy(other)" may crash. True | The current Tower implementation, if I understand it correctly, does Alg. | 2. Since `other' obeys the invariant, so will a bitwise copy of `other'. Also true. | However, if `other' has features that reference other objects, same | features in `Current' will end up referencing the same objects. If No features of Current are affected by anything in clone. In particular, the line below: Result := C_function_to_malloc_and_bcopy(other); has no effect whatsoever on Current nor does it use Current in any way. Current is an innocent bystander. (This is one of the reasons I prefer twin over clone, but that is a different matter entirely.) Only Result is changed (created and initialized) by the above code. | `copy(other)' is immediately called, this aliasing can destroy the | internals of `other' -- and that is exactly what happens in many of the | object structure examples in my book. The call: Result.copy(other) cannot affect `other' in any way. I'm not sure what the problem is. Am I missing something? -- Fred Hart (fhart@atlanta.twr.com) Tower Technology Corporation http://www.cm.cf.ac.uk/Tower/
