On Sun, 2002-05-12 at 15:43, Miko O'Sullivan wrote:
> From: "David Whipp" <[EMAIL PROTECTED]>
> > It it too much to ask, of the creator of a tied array, to implement
> > their code in such a way that *reading* an element of that array
> > does not have significant side-effects?
>
> Actually, I think that *is* a significant imposition. The whole point of
> tied arrays ( and hashes, scalars, etc) is that they act like arrays but
> internally do whatever they want.
>
> But.... could we go back a step? Could somebody explain why we need
> lookaheads, or perhaps what exactly a "lookahead" is in this context? Part
> of the current interface for tied arrays is that they know how long they
> are. It seems like it would be a relatively simply algorithm to say "if
> there are still elements left in the array then populate the loop variable
> with the next element and run the block. Else, leave the variables as they
> are, run the LAST block."
This brings up a concern that I've had with the idea of lazy arrays in
Perl for a while. An awful lot of things in the current Perl codebase
rely on the idea that an array (even a tied one) has a length at any
given time (even if it changes).
To change that assumption may have some serious impact on a lot of
features of the language.
You cannot, for example, reasonably do:
(0..Inf).length
You might special-case that particular one (return Inf if either
end-point of a lazy array is Inf), but this is a simple example. Tie
creates much more interestingly clever examples....
Should a tied and/or lazy array be forced to present a length on demand,
or can length return undef on indeterminate arrays?
