Isn't that a bit of a made-up problem? I've never seen (nor heard of) 
anyone even trying to attach more than one finalizer to an object. 
Disallowing it could be done, but unless there's a good reason for it 
I'm not in favor of deciding what is good policy and what isn't without 
a practical use case at hand. If you have a use-case I'd like to hear 
more about it, but if not, then *shrug*, who cares :-)

Cheers,
   - Andreas

On 9/23/2010 1:23 PM, Igor Stasenko wrote:
> Hello,
>
> i'd like to raise this subject once more, because i don't like it (or
> don't understand?).
>
> 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.
>
>