From: Paul Brannan <pbrannan@...>
Date: 2002-07-02T23:01:55+09:00
Subject: Re: Ruby implementation Q's

On Tue, Jul 02, 2002 at 06:51:15PM +0900, Justin Johnson wrote:
> Ruby is a wonderfully dynamic language.  On the fly, you can create
> variables for classes/modules/instances.  Wouldn't it be consistent to
> be able to delete them too?

Deleting an object from behind someone's back would be bad.  There's
currently no easy way to know who is holding a reference to an object
without going entering the mark phase of GC.  So if an object is
deleted, it would be very expensive to inform everyone that he has gone
away.  There's probably a whole mess of other problems to worry about as
well (such as ensuring that bad references never get used after the
object has been destroyed).

An alternative would be to never hold references to your object, but
instead to only hold WeakRefs.  It's safe to use a WeakRef to an object
after it has been destroyed, because an exception gets raised, rather
than Ruby segfaulting.  You can (usually) destroy your object (assuming
no one else is holding a reference to it), by setting your reference to
nil and calling GC.start.  Unfortunately, this is not guaranteed.

Another alternative (as Matz pointed out) is to be able to explicitly
free the resources the object is holding, but not free the object
itself.  The object will continue to exist, and would hold 20 bytes or
so in the freelist, but would be a "dead" object.  This requires the
library writer to do some work.  If you want to make sure that everyone
gets informed that the object is now "dead", then use the Observer
pattern.

Paul