From: Michael Neumann Date: 2001-10-24T18:33:20+09:00 Subject: [ruby-talk:23167] Re: Bruce Eckel's opinion of Ruby Avdi B. Grimm wrote: > On Tue, 2001-10-23 at 19:27, Michael Neumann wrote: > > Avdi B. Grimm wrote: > > > > Using this there is no need for destructors. > > > > > > I have to disagree with this statement. There *are* cases where the > > > block paradigm is simply not appropriate, and destructors are. > > > Sometimes it's possible to kludge in a solution using the block > > > paradigm; but it's not pretty. It's not a terribly rare occurance to > > > have objects which (a) /must/ release resources before being > > > garbage-collected, and (b) have non-determinate lifetimes. > > > > True. You cannot do everything with blocks. > > In Ruby you have class ObjectSpace that lets you define finalizer > > methods. This is not very nice, but it works. > > I would go so far as to say it doesn't work at all, unless I completely > failed to understand it. Once the ObjectSpace-defined constructor kicks > in, the object is *already gone*. All the destructor gets is (IIRC) the > ID of the object. I haven't yet figured out how this can be used to > free resources that only the now-deceased object posessed the keys to. > Perhaps one has to maintain some sort of global ID/Resource map, and the > destructor has to look up the resources to free via the ID...? Pardon > me but, yeeeecchhhhh! That's just horrid. It is usable. Imagine you build a layer around a very low-level database interface (e.g. ODBC or ISO/CLI). They work with handles (integers). Now you want to call e.g. SQL_FreeHandle when an object of class StatementHandle is garbage collected. All you have to do is to fill a Hash-table with the object's id as key and the low-level database handle as value. Then in the finalizer method you can lookup the hash and get the handle to free it. But again you're right. This is not very nice and clean, not to say horrid. Regards, Michael -- Michael Neumann merlin.zwo InfoDesign GmbH http://www.merlin-zwo.de