On Thu, Sep 23, 2010 at 1:23 PM, Igor Stasenko
<siguctua@gmail.com> wrote:
Hello,
i'd like to raise this subject once more, because i don't like it (or
don't understand?).
This is a straw man since actions compose. i.e. if one wanted multiple finalization actions on a single object one would create a unitary action that invoked multiple sub-actions. i.e. you can lift the problem up. If someone ever needs multiple finalization actions they can query the existing finalization action, compose this with a new finalization action and install the compound as the single action.
2¢
Eliot
In all scenarios, where i met the need to use finalization, a single
finalizer is sufficient.
Moreover, there is always a single object who controls a weak
reference, and it never leaks it out, to prevent
the case, when some other object may obtain a strong reference on it,
making it permanently held in object memory.
Multiple different finalizers for single object, from design point of
view, means that you having two different, not related frameworks,
which using same object, and want to do something when it dies.
A scenario, where its possible and userful, still don't comes into my mind.
In contrary, whenever i see a use of finalizers, its in most cases
about graceful control over external resource, such as:
- file
- socket
- external memory
and i really don't see how multiple finalizers per single resource
could do any good.
Suppose one finalizer closing a file handle, while another one
flushing it buffer cache.
Now, how you going to ensure, that one finalizer will execute first,
before another one?
And what if third framework comes into play and wants to add another
finalizer on top of that, which should do something in the middle
between flushing a cache and closing file handle?
>From the above, the only conclusion can be made: use a single
finalizer, and put all logic & operation ordering into it.
And also, prevent leakage of object pointer (such as file handle)
outside of your model, otherwise it may cause harm.
That's why i think a current WeakRegistry model provoking bad design practices.
I think a better behavior would be to raise an error, if something
wants to register finalizer twice for a single object.
--
Best regards,
Igor Stasenko AKA sig.