[gclist] Finalization and the insane postman bug.

[rog@vitanuova.com]

> > do we really need general finalisers?

> In my opinion, yes.  You clearly need them in a system that includes a
> legacy library requiring explicit deallocation/object destruction.
[...]
> Another good example is the "rope" data type that's included in the

hmm.
for any given system feature, there are bound to be many applications
one can think of that need that feature.  but conversely, it is always
possible to write that application in such a way that the feature is
not required.

when adding a feature to the language, surely one must consider in
their entirety the effects that the feature will have on the language
as a whole?  i don't dispute that general finalisers solve problems
like the ones you mention with elegant ease, but i'm not sure that the
resulting language is one that i'd find easier to use and debug.

the approach taken by the developers of Inferno/Limbo, which seems to
me quite reasonable, is that the garbage collector is used to pick off
all the easy fruit, the non-controversial memory reclamation, and a
few selected kernel-managed data structures and resources.

if you want anything else, you have to do it yourself; most APIs are
likely to require some discipline on the part of the programmer to
adhere to the semantics of that API. for years in the C world, we
malloced and freed data structures explicitly; post C, a given API
that needed a finaliser could still require explicit notification:

	x = API.getresource();
	x.dosomething();
	API.freeresource(x);

of course, this can drag in some of the old bugs (in particular,
memory leaks), but those are well understood and (relatively) easy to
find.  by going towards completely general finalisers, we exchange
this for a larger can of worms that wriggle more...

i might be old fashioned here, but i like to be able to verify the
correctness of a piece of code by inspection, and if arbitrary code is
potentially run as a result of pointer assignments, i lose that
potential, which ultimately impacts maintainability and the overall
cost of the s/w development cycle.

if we were to do a cost-benefit analysis of this feature, i think it
would be that which would ultimately swing my vote.  but then again, i
seem to spend most of my time inspecting, rearranging and fixing old
code, so i'm probably biased.

  cheers,
    rog.