avoid warnings in diagnostics.pm; pod tweaks (from Peter Prymmer
[p5sagit/p5-mst-13.2.git] / pod / perltie.pod
index 58e9c43..95de3bb 100644 (file)
@@ -184,7 +184,7 @@ methods: TIEARRAY, FETCH, STORE, FETCHSIZE, STORESIZE and perhaps DESTROY.
 
 FETCHSIZE and STORESIZE are used to provide C<$#array> and
 equivalent C<scalar(@array)> access.
-    
+
 The methods POP, PUSH, SHIFT, UNSHIFT, SPLICE, DELETE, and EXISTS are
 required if the perl operator with the corresponding (but lowercase) name
 is to operate on the tied array. The B<Tie::Array> class can be used as a
@@ -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