In message <[EMAIL PROTECTED]>
Dave Storrs <[EMAIL PROTECTED]> wrote:
> This runs into problems if you currently have an iterator extant and you
> modify the hash to which it points. Immediate suggestions on how to
> handle this would be:
>
> 1) Do what the docs currently do; tel
On Tue, 19 Sep 2000, Tom Christiansen wrote:
> >This RFC proposes that the internal cursor iterated by the C function
> >be stored in the pad of the block containing the C, rather than
> >being stored within the hash being iterated.
>
> Then how do you specify which iterator is to be reset when
Thanks to everyone for their valuable feedback on this RFC.
Clearly the proposed solution is not adequate, perhaps because
it does not address the central issue that iterators really ought
to be stateful objects, rather than statefree functions.
I don't have time to rework the proposal from scra
>Just to note: in version 2 of the RFC, it's associated with the pad of
>the block in which the C appears.
> > then what are you going to do?
>The short answer is that there is no "manual" reset of iterators.
I am concerned about that.
sub fn(\%) {
my $href = shift;
whi
On Wed, Sep 20, 2000 at 07:06:21AM +1100, Damian Conway wrote:
>> >This RFC proposes that the internal cursor iterated by the C
>> >function be stored in the pad of the block containing the C,
>> >rather than being stored within the hash being iterated.
>>
>> Then how do you s
> >This RFC proposes that the internal cursor iterated by the C
> >function be stored in the pad of the block containing the C,
> >rather than being stored within the hash being iterated.
>
> Then how do you specify which iterator is to be reset when you wish
> to do that? Curr
>This RFC proposes that the internal cursor iterated by the C function
>be stored in the pad of the block containing the C, rather than
>being stored within the hash being iterated.
Then how do you specify which iterator is to be reset when you wish
to do that? Currently, you do this by specif
