[Prev][Next][Index][Thread]
Re: Object lifetime management
On Wednesday, July 11, 2001, at 09:30 pm, Brad Settlemyer wrote:
> One needs only to look at the JDBC api for Java to see that all java
> resource management must be done manually (by calling close), and it is
> extremely limited.
You get destructors in Java. Calling close() makes sure that you dispose
of the resources when *you* want, not when the GC decides to call the
destructor. This is control and efficiency, not a failing.
> One need only consider the case of needing to destruct
> a concrete derived class that has obtained resources, as well as its
> parent
> class that has obtained resources.
In Dylan, next-method() will do this. In C++, forgetting to make a
destructor virtual will not do this. I've seen *experienced* C++ gods
forget to do this.
> In all the papers I've read about Dylan (which is admittedly few), they
> tout the better encapsulation system (generic functions, class data, and
> modules), optional type checking, automatic memory management, but no
> discussion of object lifetime issues. I don't have a problem
> letting a
> library manage the resources for me, but I've got to have a mechanism to
> tell the computer to manage those resources.
> It appears to me that many
> languages with garbage collection have missed the boat, memory is not
> the
> only resource I need to have managed, yet that is the only resource they
> will manage. And then they don't give me a well supported polymorphic
> way
> to manage those resources (ala C++ destructors).
I was implementing a little GUI library in Dylan. I needed to dispose of
the OS window resource. I know, I thought, I'll put the code to do this
in the destructor.
What destructor?
I worried about this for a while until I realized two things:
1. In C++, the destructor is basically a method called delete() which
the user has to call, and it had better have been declared virtual.
2. I don't want those window resources hanging around until the GC
deallocates the entire object anyway.
In particular, the separation of object deallocation from resource
deallocation seen in 2 can make sense in some situations. For example
for an object that populates itself using very heavy resources, then
gets rid of them whilst itself remaining. You can re-factor such an
example, but you'll then most likely end up with a facade that has the
same apparent functionality.
So I added the deallocation code to a close() method that gets called
when the window is closed. The window has to be hidden when it's closed
anyway.
> Essentially, in C++ the way you declare the variable determines its
> lifetime. This is both good and bad, as it allows automatic lifetime
> management (instances on the stack), but without third party libs, it
> won't
> manage instances on the free store. (The reasons I am interested in
> leaving C++ are not related to its lifetime mgmt scheme, which I
> consider
> flexible and sufficient)
Resource usage does not follow an arbitrary pattern. The assumption that
resources must last for the life of an object is not always correct, and
may be inefficient or produce an artificially extended class hierarchy
to make sure each resource is matched to an object lifetime.
There's nothing to stop people adding delete() methods to their Dylan
objects and calling next-method() in them. It's like adding ~Object() to
a class and remembering to make it virtual. In either case, there's
nothing to prevent more efficient or better-fitting resource management
schemes being used.
- Rob.
--
"The idea behind Dylan—to offer a range of dynamism appropriate to each
piece of an application—feels right, and after using Dylan you will
become frustrated with C++ and Java."
- Peter Norvig, Software Developer Magazine.
Follow-Ups:
References: