garbage collection / cyclic references

[Aaron Brady]

On Mar 21, 7:54 am, "andrew cooke" <and... at acooke.org> wrote:
> Paul Rubin wrote:
> > "andrew cooke" <and... at acooke.org> writes:
> >> the two dominant virtual machines - .net and the jvm both handle
> >> circular
> >> references with no problem whatever.
>
> > AFAIK, they also don't guarantee that finalizers ever run, much less
> > run in deterministic order.
>
> i think you're right, but i'm missing your point - perhaps there was some
> sub-context to the original post that i didn't understand?
>
> finalizers should not be considered part of a public resource management
> api - they should not be used to do things like flushing and closing
> files, for example.   i think this was a minor "issue" early in java's
> adoption (i guess because of incorrect assumptions made by c++
> programmers) (in python the with context is a much better mechanism for
> this kind of thing - the best java has is the finally statement).  but
> it's one of those things that (afaik) isn't an issue once you fully
> embrace the language (rather like, say, semantically meaningful
> indentation).
>
> but i'm sure you know all that, so i'm still wondering what i've missed.
>
> andrew

Theoretically, my object should be able to maintain an open resource
for its lifetime; and its clients shouldn't need to know what its
lifetime is.  Therefore, it needs a callback when that is over.

If finalization methods could be called in a structurally sound
manner, they could be relied on to handle flushing and closing files.

> 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?