"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [H]ow about a table that looks like this:
>
>                 next D          next N          all D           all N
>                 ======          ======          =====           =====
>     $iter       $iter.pull      ?1              $iter.pull      ?2
>     @array      @array.pull     @array.values   @array.pull     @array
>     $array      $array.pull     $array.values   $array.pull     @$array
>     %hash       %hash.pull      %hash.values    @array.pull
%hash.values
>     $hash       $hash.pull      $hash.values    @array.pull
$hash.values
>
> After all, a pull is the other end of a push.
>
> Larry

True in real life, but why not pop as the destructive evil twin of push?

I think 'pop' more clearly indicates a removing iteration than 'pull'. And
its 25% shorter!
But mainly because it's an established term for the exact concept we're
going for here.

A different concern I have, though, is this distinction we're assuming in an
iterator between destructive (DS) and non-destructive (ND). It seems to me
that, generally speaking, that should be an implementation detail of the
iterated-upon object. For example, I might be reading lines from an
arbitrary input stream. If the stream is stdin, this is clearly a
"destructive" operation, in the sense of being non-reversible. However, the
stream could just as easily be backed by a file on disk, where reading lines
does not destroy or remove them. I shouldn't have to think about which
method to use since I don't care about the effect. Huffman-wise, I imagine
that's actually the most likely iteration scenario.

I think the general iteration API should therefore be a via a name that does
not care whether its underlying object is being consumed or not (the Callous
Iterator). The syntactic <> should behave exactly this way. Then, for those
occasions you do care about how the sequence is being processed, you can
call either $seq.pop or $seq.next (or whatever names) for the specific DS/ND
behavior you need.

-Dov Wasserman


Reply via email to