2009/10/23 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sorry for the extra message. Â Outlook - need I say more?
Hello all,
I have started to port some of my code that relies on Dolphin's finalization. Â The idea is that one sends #beFinalizable to the object requiring finalization. Â Dolphin sets a flag on the object (in its header??) that the vm later notices. Â The end result is the object in question receives #finalize and cleans up its own mess; it can also "cheat death" but I doubt I have need for that level of control.
My question is that the Squeak/Pharo design appears to be built on ObjetFinalizer instances that are associated with finalizable objects, each recording what to do when an object expires. Â If that's true, then I'm wondering why objects understand #finalize. Â That seems to conflict with #toFinalize:send:to:with:, which looks like it expects just enough information to do the cleanup for the expired object.
you can use #add:executor: and provide a custom executor for object. An ObjectFinalizer just a generic class provided for convenience. Anyways, all of this stuff ends up in WeakRegistry, so its a question of personal taste, what to use. Or, if you think you are hardcore, you can write own class which provides finalizatin services. Then you can add it to: WeakArray addWeakDependent: yourStuff. And at each GC cycle, when finalization process will awake, your object will receive #finalizeValues mesasge, where you free to choose what to finalize and how.
Any idea what I might be missing here or pointers to required reading? Â I found something from 2003 (Squeak 3.7) which might be out of date, or maybe I'm just working too late :)
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.