------art_23819_162370.1132935286481
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 11/25/05, Daniel Schierbeck <daniel.schierbeck / gmail.com> wrote:
>
> Hugh Sasse wrote:
> > On Sat, 26 Nov 2005, Daniel Schierbeck wrote:
> >
> >> 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 find this tricky too: the only model I can think of is that where
> > you need destructors, your constructor desstructs, and you get at
> > the object with a block, in the style of open("file"){|f| ...}; if
> > you see what I mean.
>
> No, not really. I really can't stretch enough that I'm a noob... :)
>
>
> >> 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.
> >
> > But there is only one nil in the system, so it can't have many ids.
>
> Could the object then by replaced by a reference to the nil object?
> Again, I'm talking theoretically...
>
>
> Cheers,
> Daniel
>
>
Matz has also said that define_finalizer was in ObjectSpace on purpose to
discourage the use of finalizers. Finalizers are kind of weird, I would
recommend adding a clean-up method to any object you think "needs" a
finalizer. At least then the object still exists as in in a known state. Try
to not to think of them as destructors (in C++ sense) because they aren't.

------art_23819_162370.1132935286481--