Resync with mainline prior to post-5.6.0 updates

[perl5.git] / pod / perltie.pod

diff --git a/pod/perltie.pod b/pod/perltie.pod
index 9204052..95de3bb 100644 (file)
--- a/pod/perltie.pod
+++ b/pod/perltie.pod
@@ -743,6 +743,7 @@ a scalar.
     package Remember;
 
     use strict;
+    use warnings;
     use IO::File;
 
     sub TIESCALAR {
@@ -845,7 +846,8 @@ have not been flushed to disk.
 Now that you know what the problem is, what can you do to avoid it?
 Well, the good old C<-w> flag will spot any instances where you call
 untie() and there are still valid references to the tied object.  If
-the second script above is run with the C<-w> flag, Perl prints this
+the second script above this near the top C<use warnings 'untie'>
+or was run with the C<-w> flag, Perl prints this
 warning message:
 
     untie attempted while 1 inner references still exist
@@ -860,14 +862,11 @@ called:
 =head1 SEE ALSO
 
 See L<DB_File> or L<Config> for some interesting tie() implementations.
+A good starting point for many tie() implementations is with one of the
+modules L<Tie::Scalar>, L<Tie::Array>, L<Tie::Hash>, or L<Tie::Handle>.
 
 =head1 BUGS
 
-Tied arrays are I<incomplete>.  They are also distinctly lacking something
-for the C<$#ARRAY> access (which is hard, as it's an lvalue), as well as
-the other obvious array functions, like push(), pop(), shift(), unshift(),
-and splice().
-
 You cannot easily tie a multilevel data structure (such as a hash of
 hashes) to a dbm file.  The first problem is that all but GDBM and
 Berkeley DB have size limitations, but beyond that, you also have problems