From: Jarkko Hietaniemi <jhi@iki.fi>
Date: Fri, 5 Sep 2003 13:53:23 +0000 (+0000)
Subject: One more known tie problem.
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=e77edca30a2be27033e243f6b69dee5191c27b5a;p=p5sagit%2Fp5-mst-13.2.git

One more known tie problem.

p4raw-id: //depot/perl@21048
---

diff --git a/pod/perltie.pod b/pod/perltie.pod
index 7b8d497..4befdae 100644
--- a/pod/perltie.pod
+++ b/pod/perltie.pod
@@ -1080,6 +1080,13 @@ regardless of whether the hash is empty or hash elements).
 Localizing tied arrays or hashes does not work.  After exiting the
 scope the arrays or the hashes are not restored.
 
+Counting the number of entries in a hash via C<scalar(keys(%hash))>
+or C<scalar(values(%hash)>) is inefficient since it needs to iterate
+through all the entries with FIRSTKEY/NEXTKEY.
+
+Tied hash/array slices cause multiple FETCH/STORE pairs, there are no
+tie methods for slice operations.
+
 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
@@ -1091,10 +1098,6 @@ source code to MLDBM.
 Tied filehandles are still incomplete.  sysopen(), truncate(),
 flock(), fcntl(), stat() and -X can't currently be trapped.
 
-Counting the number of entries in a hash via C<scalar(keys(%hash))>
-or C<scalar(values(%hash)>) is inefficient since it needs to iterate
-through all the entries with FIRSTKEY/NEXTKEY.
-
 =head1 AUTHOR
 
 Tom Christiansen