On 24 September 2010 00:09, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 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¢

Right, i am exactly about that - lift the problem up.
The entity, which holding an exclusive control over some external resource,
may do a composite actions while finalizing it.
And from WeakRegistry side it should be seen as a single finalization
action, not multiple ones.

Because otherwise, as i said before, allowing installing multiple
finalizations using WeakRegistry,
feels like two (or more) unrelated entities trying to hold an
exclusive control over some resource.
Which never should happen in well-designed model.

> 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.
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.