On 11 October 2010 18:23, Henrik Johansen <henrik.s.johansen at veloxit.no> wrote:
>
> On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote:
>
>>
>> I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point.
>>
>> Bill
>
> I fail to see how a blatantly obvious misuse of a feature becomes a valid argument against supporting that feature, or something you should worry alot about.
> You can do Object become: nil, which is also not good style, but it's certainly not an valid argument for not allowing #become:.
> Nor do I lose any sleep thinking of ways people could possibly abuse #become:
>

Henrik, in previous discussion i shown that multiple finalizers could
be effectively replaced with multiple
private weak registries.
There is one good reason for that: do not let anyone else to do
something 'good' with your private stuff.
Because 'good' quite often turns out to be 'bad', once you leaking a
reference to some critical object outside your model.

See
http://www.erights.org/index.html#SmartContracts

multiple finalizers per object is not a product of a smart contract.
Because it means that same object accessible by two different,
unrelated frameworks, which then will attempt to race for its
ownership as to 'who's gonna finalize it first', or 'who having right
to remove it from weak registry etc'.


More to that, in context of current discussion, i see that multiple
finalizers adding a lot of complexity for implementing
correct error handling.



> Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.