From: "RadosÅ‚aw BuÅ‚at" Date: 2008-01-11T06:26:11+09:00 Subject: Re: why does this code leak? On Jan 10, 2008 10:15 PM, Robert Dober wrote: > On Jan 10, 2008 9:03 PM, Rick DeNatale wrote: > > On 1/10/08, Tim Pease wrote: > > > On Jan 10, 2008, at 5:26 AM, Robert Dober wrote: > > > > > > > class Foo > > > > def initialize > > > > ObjectSpace.define_finalizer self, lambda{} > > > > end > > > > end > > > > > When you create the lambda, what is the value of "self" inside the > > > lambda? > > > > > > The answer is that it is going to be the object in which the lambda > > > was created. In the code above, this would be the object that you are > > > trying to finalize -- i.e. an instance of Foo. Since the lambda has a > > > reference to the Foo instance, that instance will always be marked by > > > the GC, and hence, it will never be garbage collected. > > > > Right, > I honestly fail to see why the closure shall take a reference to the > object . I am with Ara here, no need to keep a reference to the object > and this is not only MHO but also that one of Ruby1.9;), if not a bug > at least it is odd behavior. I thought the same at first time. Read http://ola-bini.blogspot.com/2007/12/ruby-closures-and-memory-usage.html and you should change opinion. 2 comments from post: "Many languages have compilers that perform analysis on the closures and capture only the variables it actually closes on; This includes the "self" variable of the instance. This is not currently the case with Ruby? Is there any reason why the compiler could not be implemented in such a way?" Ola response: "Tomas: yes, there is a marvelous reason for this: eval. There is no way for the parser to know which variables will be used at any point. The price you pay for a VERY dynamic language." -- Rados³aw Bu³at http://radarek.jogger.pl - mój blog