Explain that destruction order is not defined

Subject: Re: perl debugger problem with object destructors?

On Wed, 14 May 1997 15:12:38 MDT, Tom Christiansen wrote:
>
>Actually, deterministic destruction/finalization is oft-deemed
>a feature.   If you could check what perltoot has to say about destructors,
>gsar, and suggest an appropriate patch if necessary, I'd appreciate it.

I'd say something like this:

p5p-msgid: 199705150600.CAA13550@aatma.engin.umich.edu

diff --git a/pod/perltoot.pod b/pod/perltoot.pod
index 0c5b418..bfe1da2 100644 (file)
--- a/pod/perltoot.pod
+++ b/pod/perltoot.pod
@@ -263,7 +263,11 @@ clean-up code is placed in the destructor, which must (in Perl) be called
 DESTROY.
 
 If constructors can have arbitrary names, then why not destructors?
-Because while a constructor is explicitly called, a destructor is not.
+Because while a constructor is explicitly called, a destructor is not,
+the implication being that Perl either always knows the right time to
+call a destructor, or wants to reserve the right to decide for itself.
+Perl's notion of the "right time" is not well-defined currently,
+which is why your destructors should not rely on when they are called.
 Destruction happens automatically via Perl's garbage collection (GC)
 system, which is a quick but somewhat lazy reference-based GC system.
 To know what to call, Perl insists that the destructor be named DESTROY.