garbage collection / cyclic references

[Aaron Brady]

On Mar 21, 9:50 am, "andrew cooke" <and... at acooke.org> wrote:
> Aaron Brady wrote:
> > On Mar 21, 7:54 am, "andrew cooke" <and... at acooke.org> wrote:
> >> they should not be used to do things like flushing and closing
> >> files, for example.
> > What is your basis for this claim, if it's not the mere unreliability
> > of finalization?  IOW, are you not merely begging the question?
>
> I'm not sure it's clear, but I was talking about Java.
>
> As Paul implied, a consequence of completely automated garbage management
> is that it is (from a programmer's POV) deterministic.  So it's a
[indeterministic]
> programming error to rely on the finalizer to free resources that don't
> follow that model (ie any resource that's anything other that
[than]
> reasonable
> amounts of memory).
>
> That's pretty much an unavoidable consequence of fully automated garbage
> collection.  You can pretend it's not, and try using finalizers for other
> work if you want.  That's fine - it's your code, not mine.  I'm just
> explaining how life is.
>
> Andrew

Hi, nice to talk to you this early.  Sorry you're in a bad mood.
You've sure come to the right place to find friends though.  </tongue
in cheek>

My point is, that garbage collection is able to detect when there are
no program-reachable references to an object.  Why not notify the
programmer (the programmer's objects) when that happens?  If the
object does still have other unreachable references, s/he should be
informed of that too.

I advanced an additional method to this end.  Do you argue that there
aren't any cases in which the class could make use of the information;
or there aren't /enough/ cases so in which?

Perhaps it would help to handle a contrary case by hand.  Two objects
need to make write operations each to the other when they are closed.
Would it be sufficient in general, knowing nothing further about them,
to queue some information, and close?  Do they always know at design-
time their references will be cyclic?  Would a mere
'__leave_reachability__' method be more generally informative or
robust?  Would it constitute a two-step destruction, to notify objects
when they're unreachable, and then finalize?  The two objects' write
operations could execute in such a method, without risking prior
destruction.