From: Brian Candler <B.Candler@...>
Date: 2003-05-20T01:18:13+09:00
Subject: Re: An Object Going Out Of Scope

On Tue, May 20, 2003 at 12:55:22AM +0900, MikkelFJ wrote:
> I didn't go through all you examples, but I did say that you could still
> have references at time of finalization.

But then what is the purpose of a "finalizer"?

It's possible for an object to be assigned to a variable which goes out of
scope lots of times!

   a = Foo.new
   1.times {
     b = a       # b is created
   }             # b goes out of scope
   5.times {
     c = a       # c is created for each invocation of the block
   }             # c goes out of scope 5 times!

Would you really want to call a finalizer 6 times on the same object in the
above example? I don't think so.

I think you are proposing that the variable itself can be tagged in a
special way, "do X when this variable goes out of scope". But you can
achieve this using 'ensure' already, without having to get the interpreter
involved:

    a = Foo.open(...)
    begin
      ... whatever
    ensure
      a.close   # always done, even if an exception occurs
    end

> In a block you have { |resource| ... }
> When the block terminates, resource.cleanup is called. However, what
> prevents you from storing references to the resource all over the place: {
> |resource| $nasty_global = resource }?
> Thus auto cleanup isn't more or less safe than using auto as in D.

Absolutely. But it's a clear programming pattern which makes the intention
pretty clear: set up resource, yield to block, close resource. There is no
magical invocation of extra methods just because a local variable has
expired.

> { auto(:$critsec, :exit); @critsec.enter; .... }

That doesn't make any sense to me - a global variable can never go out of
scope?

Regards,

Brian.