From: Thomas Hurst Date: 2002-02-24T11:56:00+09:00 Subject: Re: Object/Memory Management * Sean O'Dell (sean@celsoft.com) wrote: > "Jim Weirich" wrote in message > news:m2wux3bys2.fsf@skaro.access.one.net... [SNIP] > I just know that being able to call a finalize method *before* the > object is one of the great things about OOP. You can encapsulate > activities inside an object without the outside world knowing > everything going on inside, and they can use it safely. Look at http://www.rubygarden.org/ruby?DiscussionOnUsingFinalizers for how finalizers work in the Ruby scheme of things. Basically you define finalizers for resources inside your object, not your object itself; if you need to do a @file.close, you define a finalizer for @file itself, rather than for your object, which then needs to access self.file, which of course no longer exists (yes, I know that's a really, really bad example, never mind, it's 3am :) Also it appears Matz had some trouble implimenting it, so he made it ugly to discourage it ;) > > 1) To recover memory > > 2) To release non-memory resources > > 3) To use the "resource allocation is acquisition" idiom (RAIA) > > With GC, (1) isn't much of a motivator. A good GC collector will > > generally outperform most manual allocation/destruction schemes. > > With the inherit dangers involved with explicit destruction > > (dangling pointers, etc), it just doesn't seem worth it. > > I don't know enough about garbage collection, but that's what everyone > is saying so I'm accepting that on faith right now. Well, the thing with 1) is you don't gain much destroying objects aggressively (i.e. deleting them explicitly) since Ruby's process size never shrinks (that's a common feature of malloc()/free() anyway, maybe that's why, *shrug*); all you gain is being able to release a few external resources slightly earlier. Otherwise you're just asking the system to destroy your objects, having them gc'd straight away (after a nice run around the system to make sure nobody references it) and getting nothing but a few extra entries on the free list in Ruby. So all you end up doing with explicit object deleting is some wasted CPU and maybe dropping a few external resources; not a big motivator concidering the complexities involved in implimenting it with the GC and the performance hit it produces. > > If (2) is your concern, there is nothing stopping you from doing an > > explicit release of your non-memory resources. For example, if you > > want to make sure a file is closed when you are done with it, then > > close it. Don't depend on object destruction to close the file. I'd recommend this anyway; if you want your object to save it's state on exit, wrap access to it's state in blocks and have a begin .. yield .. ensure .. end block, or have an explicit call to commit the state of the object. Better to have these things fail when the object is in a healthy state and be able to do anything with it, such as maybe Marshal it to disk if your original state saving stuff failed, than be inside a finalizer and have to avoid talking about the object itself. -- Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ - The hidden flaw never remains hidden.