At 12:03 AM 10/3/00 +0100, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Also, don't assume that the key passed in is just a string. It could well
> > be a string/hashval pair, or a string/hashval/magic triple, and we use the
> > fast m
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
TH> In other words, it's just a generic iterator state object... The
TH> way I'd like to see things work is that hashes, arrays etc have a
TH> vtable method that returns an iterator object. That iterator object
TH> then has whatever opa
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Also, don't assume that the key passed in is just a string. It could well
> be a string/hashval pair, or a string/hashval/magic triple, and we use the
> fast method with the others as fallbacks.
In other words, it
In message <20001002221632$[EMAIL PROTECTED]>
Uri Guttman <[EMAIL PROTECTED]> wrote:
> hmm, that means 'next' does a lookup based on the key passed
> in. currently next uses the iterator state which is much faster. i think
> next should be faster than a regular lookup but the semantics
At 06:09 PM 10/2/00 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> I'm currently leaning towards having a "next" entry in the vtable
> DS> that takes a key value and returns the next entry in the
> DS> (hash|array|sparse array|bitmap|string) and le
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I'm currently leaning towards having a "next" entry in the vtable
DS> that takes a key value and returns the next entry in the
DS> (hash|array|sparse array|bitmap|string) and leave it at that. No
DS> state per se--if the key we're
At 04:38 PM 10/2/00 -0400, Uri Guttman wrote:
>now we still have the problem of designing a clean iterator object that
>will work with perl hashes. the usual questions arise: what happens if
>you modify the hash during the iteration? where is the state of
>iteration stored (in the object most like
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I'd rather not store the iterator in the optree or, if we do, make
DS> it lexically scoped. I'd actually *really* like to make iterators
DS> explicit objects all by themselves, but it's too much work for
DS> most uses of iterators
At 11:12 PM 9/30/00 +0200, Bart Lateur wrote:
>On 28 Sep 2000 19:40:01 -, Perl6 RFC Librarian wrote:
>
> >=head2 How iterators might work in perl 6
> >
> >In perl 6 the keys and values functions should no longer use the
> >same iterator as the each function - each use of keys and values
> >sho
On 28 Sep 2000 19:40:01 -, Perl6 RFC Librarian wrote:
>=head2 How iterators might work in perl 6
>
>In perl 6 the keys and values functions should no longer use the
>same iterator as the each function - each use of keys and values
>should use it's own private iterator instead.
Is that per Da
10 matches
Mail list logo
