Nicholas Clark <[EMAIL PROTECTED]> wrote: > When writing morph methods for PMC classes, am I right in thinking that if > morphing from class A to class B, where both use the PMC_struct_val to > store structures of different types, it's totally up to the morph method > to know how to correctly dispose of the old class A structure, and create > and initialised a class B structure?
> In effect morph has to be friends of both A and B, because it needs to break > encapsulation? Yep. The same is true for C<assign_pmc>, which additionally to C<morph>, gets the value from A and sets it on B. And: A = new Complex B = new Integer A = "1+2i" morph A, .Integer # oops memory leak or assign A, B # same Ok, that can be solved by calling A.destroy() first. But what happens, if A has finalizers, which may depend on other finalizers? But there is more weirdness: A = new Env morph A, .Integer # error "Parrot VM: Can't modify a singleton" or assign B, A # error "Parrot VM: Can't turn to a singleton type!" The necessity for C<morph> and C<assign> is basically due to the (now almost gone) inability to create new values in unary and infix operations. *But* there is the problem with Perl references, which seems to create a need for such a behavior. $a = 4; $b = \$a; $a = 41; ++$$b; print $a; # 42 It probably just depends on the implementation of Perl5 references. > Nicholas Clark leo
