Jim Weirich wrote:
> dasch wrote:
>> In that case I'd expect $global_reference to be nil after the `finalize'
>> method is done executing, since the Klass instance has already been
>> deemed ready for destruction.
> 
> "after the 'finalize' method is done" => Tricky.
> 
> How would this be implemented?  Seems to me Ruby would have to scan all 
> of the current image to determine if any new references were created 
> during the execution of the finalize method.  Especially since the 
> references may be created deep inside other methods invoked by finalize.
> 
> And it might be more subtle than just checking for variable bindings. 
> Consider:
> 
>   class NamedObject
>     attr_reader :name
>     def initialize(name)
>       @name = name
>     end
>     def finalize
>       proc { name }
>     end
>   end
> 
>   k = NamedObject.new("Billy")
>   p = k.finalize  # Here p is a proc that has a binding that includes
>                   # a "finalized" object.
> 
> The point is that the current mechanism avoids all these questions by 
> only calling the finalizer /after/ the object has been destroyed.
> 

I just think it's weird that PHP has destructors and Ruby doesn't ;)

   http://www.php.net/manual/en/language.oop5.decon.php

I'm not really into C, neither am I familiar with the Ruby 
implementation, but doesn't all variables just reference an object? So 
somewhere, an object is stored, and each variable referencing it really 
only holds that object's id. I imagine the `finalize' method could be 
run, and afterwards, the object could be replaced with nil, maybe 
retaining the old object id. That way any variables that point to the 
object will be nil.

Now, I don't know if that's how it works, but it sounds logical to me, 
speaking as a guy who's never taken any programming lessons or 
programmed/scripted using other languages than PHP, JavaScript and Ruby...


Cheers,
Daniel