Re: Re^3: map-like hash iterator

[jdporter]

Of course, if you're not in void context and actually intent on returning the resulting list from processing a 10,000,000 key hash, you'll have to be able to fit that in memory anyway.

Not necessarily always the case, though. The callback routine might never return anything -- except one time when it returns one thing. A jillion-key hash in, a one-element list out.

Just like map.

UPDATE

You can't have your cake and eat it - you can't be using an iterator when you're concerned about memory usage.

That is patently false. In fact, the built-in hash iterator (each) is all about efficiency -- in both space and time.

There is no reason why iterators can't be efficient.

[Aristotle]

That would be grep ;-) Still, that can be pretty wasteful. Why iterate over the entire 10,000,000 records even when the single one of interest is found at the very beginning? The iterators do not offer any early bailing mechanism.

You have to look at the larger picture.

Iterators mainly offer convenience. There are very few situations where iterators are useful under big efficiency concerns (be it memory or time), in the absence of lazy lists. Even so, you can't go wrong with the explicit loop construct.

This ain't Ruby. :-) Perl 6 will, however, have lazy lists. (Is there anything Perl 6 won't fix? :-))

Makeshifts last the longest.

[jdporter]

Why iterate over the entire 10,000,000 records even when the single one of interest is found at the very beginning? The iterators do not offer any early bailing mechanism.

False. die works just fine.

Iterators mainly offer convenience.

And this is Perl. Sounds like a perfect match.

Anyway, if you want to argue about it, let's meet in the chatterbox some time. Thank you for your comments.

[Aristotle]

die works just fine.

But how do you return the result then? Anyway.. :)

Makeshifts last the longest.