At 01:49 PM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 11:30 AM 8/23/00 -0700, Larry Wall wrote:
>: >Dan Sugalski writes:
>: >: I have had the "Well, Duh!" flash, though, and now do realize that having
>: >: multiple iterators over a hash or array simultaneously could be rather
>: >handy.
>: >
>: >You can also have the opposite "Well, Duh!" flash and realize that most
>: >DBM implementations only support a single iterator at a time. For some
>: >definition of support. That's the main reason for Perl's current
>: >limitation.
>:
>: Fair enough. Removing the limit makes sense, though, both from a
>: flexibility and a thread-safing standpoint. Might make sense for the
>: hash/array slices the PDL folks want too, if that's how they get
>: implemented, since I can see wanting to have many different hash or array
>: slices.
>
>No problem with that. We can always catch the DBM limitation at
>runtime, and we're no worse off than we are now, unless people expect
>to be able to turn on hash persistence transparently by tying to DBM.
>
>But in actual fact, we almost always use keys rather than each, so it
>probably doesn't matter.
Might not, but each gets used more with tied hashes, so it kinda collides
with the DBM limits.
Plus I can see each being used more often if we extend it to be valid for
sparse arrays, or used more under the hood with iterators and lazy lists
and suchlike things. Each, when used on a sparse array, would presumably
return a list of offset/value pairs of valid entries in the array. Keys and
values would also, presumably, be extended to work with them. On non-sparse
arrays too, I suppose, though the lack of holes in them doesn't give
each/keys/values much benefit over other methods of accessing the data in
an array.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
