On Sun, Apr 24, 2005 at 09:25:43AM +0200, Leopold Toetsch wrote: > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > When writing morph methods for PMC classes, am I right in thinking that if
> > 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? Doesn't this mean that there's a split here in "finalizer"s that's not being made. Some finalization actions relate to "free up the memory" of this PMC. Others relate to "this PMC is going away". And as morph involves changing the internal memory layout of a PMC without it actually going away, only the first set ought to run. If the two types of action were properly split, would it help solve the problems? Anyway, for ponie I'm starting to think that I don't actually need formally different PMC types, as long as I can change the vtable on a PMC. Is that possible? Or is the only sensible way to change vtables (and generate 16+ variants) to have different PMC classes? Nicholas Clark
