Igor,

On Thu, Sep 23, 2010 at 1:23 PM, Igor Stasenko <siguctua at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100923/fc06b3cf/attachment.htm