Re: Object/Memory Management

>>>>> "Sean" == Sean O'Dell <[e-mail]> writes:

Other responses addressed your explicit destruction question ... I'll
give a response to your second question.

    Sean> Also, a related issue...why isn't there a finalize call?  I
    Sean> don't mean the finalizer where you can set a method to get
    Sean> called after an object is gone, I mean, why isn't there a
    Sean> call to an object's "def finalize...end" right *before* an
    Sean> object goes away?  Is that in the works or is that just not
    Sean> the Ruby way?

Java does it the way you suggest, but it leaves a rather nasty
possibility open.  Suppose that the finalize method created a *new*
reference to your object that is in the processes of being destructed
(probably something you shouldn't do, but it *can* be done).  Since
there is now a reference to the object, the object is now "live" again
and it can no longer be garbaged collected.  What a situation, you
have a live object whose finalizer has already been run.  When the
object is garabage collected for real later, the finalizer will not be
run again.

Ruby avoids this weird situation by running the finalizer code *after*
the object is already collected.  You arrange for a closure to handle
the resources that need handling during finalization, but the closure
has no reference to the original object, therefore it can't create a
new reference to it.  In addition, Matz made the finalization code
just a little clunky on purpose, to discourage using it gratuitously.

    Sean> I don't fully understand why explicit object destruction
    Sean> doesn't exist and why there is no object finalize call.  Is
    Sean> it against Ruby philosophy and will never be there, or is it
    Sean> just that Ruby is still young and it hasn't been implemented
    Sean> yet?

There are several reasons for using explicit object destruction...

 1) To recover memory
 2) To release non-memory resources
 3) To use the "resource allocation is acquisition" idiom (RAIA)

With GC, (1) isn't much of a motivator.  A good GC collector will
generally outperform most manual allocation/destruction schemes.  With
the inherit dangers involved with explicit destruction (dangling
pointers, etc), it just doesn't seem worth it.

If (2) is your concern, there is nothing stopping you from doing an
explicit release of your non-memory resources.  For example, if you
want to make sure a file is closed when you are done with it, then
close it.  Don't depend on object destruction to close the file.

As for (3), a lot of people from the C++ world use explicit object
destruction combined with the stack based allocation available in C++
to manage resources.  For example, the following code will make sure
the ifstream "f" is closed when the function exits and "f" is
automatically destructed.

   void func () {
     ifstream s("data.txt");
     // Use input file stream f here
   } // f goes out of scope here     

Ruby has a different idiom that handles this case.  We wrap
open/close, allocate/deallocate, or any other paired operation in a
function and pass that function a code block to execute.  The Ruby
version of the abover file example would be ...

    def func
      open("data.txt") do |f|
        # Use file f here
      end  # automatically close f when the block is done
   end

This technique is used extensively in the Ruby DBI library.  One of my
favorites is the transaction { ... } method.

I've also done similar things with semaphores and locks.  For example
...

   def synchronize(lock)
     lock.acquire
     yield
   ensure
     lock.release
   end

   # usage ...
   synchronize(a_lock) do
     # do somethine while we have a lock
   end

... is a practical replacement for Java's synchronized block
statement.  The idiom is more flexible and actually easier to use than
the RAIA idiom in C++.

Perhaps you see a need for explicit destruction that I haven't
covered.  If so, I'd like to hear of it.

Sorry, I got a little more long winded than I intended.  I hope this
helps.

-- 
-- Jim Weirich     [e-mail]    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)