From: Justin Johnson <justinj@...>
Date: 2002-07-03T21:53:18+09:00
Subject: Re: Ruby implementation Q's


> Now I understand.  It would reduce the cost of class variable access.
> But class variable access can rarely be the bottleneck.

Of course. In Rubys usual environment I don't think it would be a
bottleneck, not compared to regexp and file manipulation speed.  For my own
needs, i'm trying to consider how to make the core language as fast as
possible.

> Hmm, your "removing variable" means something stronger than "removing
> object".  I don't think I fully understand you.  All I can say is it
> should not be done by method or method like operation.  It requires
> special syntax.  This idea is very interesting, but I'm not sure (yet)
> whther it is worth merging.  Lisp / Smalltalk / Ruby etc. have had no
> problem with the current object model.

a = MyClass.new
    Action: Instance of 'MyClass' is created and assigned to new local
variable 'a'.  'initialize' method is called for 'a'.

a.destroy
    Action: 'unitialize' method is called for 'a'. 'a' is removed from local
variable hash. 'a' no longer exists as a variable.

Any ptr's that used to reference to 'a' are set to Nil.  This can be done as
the runtime comes across ptr's to dead objects.  This means that 'destroy'
could be implemented as a method - it wouldn't be possible to make 'a' live
again after 'destroy'.

I'll admit, it's an unusal approach for gc languages to implement voluntary
destruction.

The preference would be for finalization to be called as soon as an object
becomes unreferenced although I haven't thought of a good way of doing that.

--
Justin Johnson
justinj@mobiusent.com
Technical Director
Mobius