perlunifaq, uniintro: fix for 80 col display

[p5sagit/p5-mst-13.2.git] / pod / perlobj.pod

diff --git a/pod/perlobj.pod b/pod/perlobj.pod
index 44ae453..fdecd84 100644 (file)
--- a/pod/perlobj.pod
+++ b/pod/perlobj.pod
@@ -350,8 +350,8 @@ Usually Perl gets it right, but when it doesn't you get a function
 call compiled as a method, or vice versa.  This can introduce subtle bugs
 that are hard to detect.
 
-For example, a call to a method C<new> in indirect notation -- as C++
-programmers are wont to make -- can be miscompiled into a subroutine
+For example, a call to a method C<new> in indirect notation (as C++
+programmers are wont to make) can be miscompiled into a subroutine
 call if there's already a C<new> function in scope.  You'd end up
 calling the current package's C<new> as a subroutine, rather than the
 desired class's method.  The compiler tries to cheat by remembering
@@ -460,6 +460,15 @@ object destruction, or for ensuring that destructors in the base classes
 of your choosing get called.  Explicitly calling DESTROY is also possible,
 but is usually never needed.
 
+DESTROY is subject to AUTOLOAD lookup, just like any other method. Hence, if
+your class has an AUTOLOAD method, but does not need any DESTROY actions,
+you probably want to provide a DESTROY method anyway, to prevent an
+expensive call to AUTOLOAD each time an object is freed. As this technique
+makes empty DESTROY methods common, the implementation is optimised so that
+a DESTROY method that is an empty or constant subroutine, and hence could
+have no side effects anyway, is not actually called.
+X<AUTOLOAD> X<DESTROY>
+
 Do not confuse the previous discussion with how objects I<CONTAINED> in the current
 one are destroyed.  Such objects will be freed and destroyed automatically
 when the current object is freed, provided no other references to them exist