Functional (Meta)?Programming Stunts for Ruby and Groovy (and a Little Perl)…

However, there’s a lot of cases where deterministic resource clean-up isn’t all that important. Take, for instance, libcurl’s API, which requires global init and global clean-up to be done. The OCaml runtime will actually do a *better* job of running the global clean-up reliably than my own code will, since it has a chance to respond to things like signals which my code doesn’t address. So what’s wrong with using it there?

Resource ownership has semantic meaning. It’s not just about memory and type safety, where GC has a good application without affecting semantic meaning – a theoretical GC with infinite memory that never freed any memory would be perfectly fine. On the other hand, closing a file handle has a concrete, observable, global effect on the system – depending on the sharing mode / OS, you can’t reopen or delete an already-open file; there may be unflushed buffers in your RTL’s IO code before final closing; etc. Similarly, closing a socket will be observed by the other end; and there are analogues for most OS resources that a program can acquire.

Leaving resource cleanup to a GC via finalization is in almost all cases very bad practice.

GCs aren’t aware of the systemic effects of the various resources whose lifetimes you have associated with arbitrary objects, so these calculations won’t enter into when it considers it opportune to perform a GC. And besides, in certain cases the GC may fail to invoke finalizers for your objects altogether.

Resources need deterministic cleanup. If you find it difficult to work out ownership semantics, consider reference counting (perhaps via a handle object) or an API protocol. For example, in C# I often use an enumeration called ResourceOwnership with two values, Preserve and Transfer. Any API that takes a resource value that has a semantic ambiguity of ownership takes a value of this enumeration type. I blogged about it some time ago (http://barrkel.blogspot.com/2006/08/specfiying-ownership.html).

Just say no to finalization. It’s (almost certainly) not the answer you’re looking for.