Miko O'Sullivan wrote:
> Just checking here: is PRE_LAST a separate and non-mutually exclusive
> concept from LAST? I.e., would this make sense:
>
> foreach @arr -> $i {
> PRE_LAST {print "before last loop\n"}
> LAST {print "after last loop\n"}
> print "$i\n";
> }
>
> If so, wouldn't look-aheads still result in chaos and
> confusion for tied arrays?
Under the hypothetical PRE_LAST block, I'd expect your code to
make sense.
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?
If one is doing object oriented programming, then the concept
of substitutability requires that I can use a subclass anywhere
that I can use the base class. When I use an array, I expect
to be able to read elements from it, at random, without
breaking it. If a tied array does not permit me to read
its elements without worrying about hideous side effects,
then it is not an array.
> If not, then I'd definitely disagree: to me, for's and
> while's are just different flavors of "loop" and should
> behave the same in every way possible.
The great things about things that are different, is that
they are permitted to differ. C<while> and C<foreach> are
not synonyms. They have distinct characters.
To me, the concept of PRE_LAST makes sense in the context of
C<foreach>, and is easy to implement. In the case of a C<while>,
or C<loop> loop, the concept may still make sense: but the
details of the semantics need careful consideration. There's
a great danger of analysis-paralysis if we cogitate on the
difficult case. So perhaps we can first seek agreement on
the easy case.
Dave.
