Kitty Draper

Problem with using `defer(){}` in that situation is that it can lead to a lot of repeated code. In the logger case, consider the following two examples, assuming a Logger...

As an even more complicated example: Suppose I write a class that contains a Logger as a member. The logger is private and no one knows it's there. My class...

I'm not certain how a class decorator would solve the problem. If it forces a defer() block that destructs the class, that would break cases where the class needs to...

Point of semantics; I'm using "destructor" and "finalizer" interchangeably here when they are actually different things in some ways. Destructors are preferable to finalizers for a number of reasons but...

> A simple principle: deem any feature useless unless the opposite is proved. When you say "It's good, I use it, other folks use it", it's not sufficient. So I...

I've not used Ruby enough to say much about it, but a brief google search indicates that it basically has the same thing, just with a different interface. Don't like...

Go and Ruby seem to take the same approach. The way python does it starting with 3.4 (just as another point to look at) is that you define a method...

> It allows to dynamically add an ad-hoc finalizer to any object. That's also a nice bonus. What happens if the object already has a finalizer and someone adds an...

Seems dangerous to add them ad-hoc, then. Seems there should also be a GetFinalizer() so you can call any existing ones as well if you're adding them ad-hoc. How does...

This is the scenario where I see inheritance mattering: ``` class A { routine A() { # ... Acquire some resources ... SetFinalizer(self, Finalizer); } routine Finalizer() { # ......