From: Sean O'Dell <sean@...>
Date: 2002-02-24T12:21:58+09:00
Subject: Re: Object/Memory Management

"Jim Weirich" <jweirich@one.net> wrote in message
news:m2n0xzbq0w.fsf@skaro.access.one.net...
> >>>>> "Sean" == Sean O'Dell <sean@celsoft.com> writes:
>
> Finalization is can still encapulated within the class without the
> outside world knowing or caring.  For example, in the following code,
> only FinalizingObject knows that it needs to close the SillyResource
> when it is collected.

I will have to look again at the finalizing features...I didn't know there
was a way to set a finalizer to run *before* the object was destroyed.
Maybe my book is outdated already?

Actually, I'm probably not going to use it much anyway.  Since they're not
guaranteed to run at all, and certainly can't be run in reverse order, I
have little need of it.  If I ever use them, it will just be for emergency
purposes to free up resources.

> As do I.  I just realized that perhaps you are thinking of finalizers
> in the same way as destructors in C++.  This is the wrong way to think
> of them.  Destructors are deterministic and under the control of the
> programmer.  Finalizers are non-deterministic (as far as when they are
> run) and under the control of the run time.  (In fact, some languages
> don't even guarantee that finalizers will *ever* be run, I don't
> recall the exact semantics of Ruby finalizers).
>
> Use the block idiom for fine control of your resources.

Exactly.  I've done a lot stable code because of destructors and I'm going
to miss them...I just hope the block way holds up for me.

Thanks for all the help,

    Sean