On Sat, 2002-02-23 at 14:01, Sean O'Dell wrote:
> I'm new to Ruby and the community here (I've been learning Ruby for a grand
> total of 2 days now), so forgive me if this has already been beaten to
> death.  I have already read a lot of the archives, but I don't know what's
> being done regarding the garbage collection scheme and the lack of a true
> object destructor.
> 
> Isn't there a way we can *explicitly* destroy objects?  I like to keep
> things tight and clean in my code, and simply walking away from objects I've
> created absolutely freaks me out.  I don't like leaving my program bloated
> up in memory with objects that I really only meant to exist for just a split
> second while it did something.

You can call the GC routines to do cleanup at any time you want.

> 
> I sort of understand (just from reading the archived threads on Usenet and
> the wee bit I found in the pragmatic programmer, developers guide and
> nutshell) how garbage collection works and why it's there.  How hard is it
> to change it to allow the destruction of individual objects?  I think the
> problem is that, since reference counting sort of screws with some of Ruby's
> paradigms, it's not practical to do stack-based cleanup.  That's fine, I see
> the advantage of garbage collection.  However, what about explicit object
> destruction?  That shouldn't mess with anything.  If you can walk the
> current list of living objects to determine if one can go away, why can't
> there be a call to explicitly check and destroy one object?  Perhaps throw
> an exception if it can't go away yet, to let the programming know during
> debugging that he needs to move to call somewhere else.

I'm assuming that you want the memory usage low for
performance/efficiency reasons?  If so, realize that GC is *faster* than
explicit garbage collection... the memory management is only done when
its needed, plus is reduces the amount of tiem spent
allocating/deallocating memory (which is quite slow).

I don't see reference counting ever being added to Ruby, simply because
reference counting breaks way too easy.  With reference counting, almost
any major program is guaranteed to end up with a memory leak (objects
that reference each other, but by nothing else, will never get cleaned
out of memory).

The reason explicit object destruction can't work is because the
interpreter has no idea what objects reference the object you are
destroying.  You could very easily cause dangling pointers, and then a
crash not too long afterwards.  The best thing to do is, after you are
sure you want the object destroyed, call the GC routines.  That will
clean up the object, but *only* if it isn't referenced by anything.

As for the exception idea you mentioned, that would more or less just be
calling the GC, but then marking whether a particular object is gone or
not.  You could get the error that your program needs to unref the
object from somewhere else, but what advantage would that be?

> 
> Also, a related issue...why isn't there a finalize call?  I don't mean the
> finalizer where you can set a method to get called after an object is gone,
> I mean, why isn't there a call to an object's "def finalize...end" right
> *before* an object goes away?  Is that in the works or is that just not the
> Ruby way?
> 
> I don't fully understand why explicit object destruction doesn't exist and
> why there is no object finalize call.  Is it against Ruby philosophy and
> will never be there, or is it just that Ruby is still young and it hasn't
> been implemented yet?
> 
>     Sean
> 
>