Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
what about
while (do_something_with_side_effects_and_check_still_ok()) {
I presume we don't want to do look-ahead here.
Yes, I think he was saying exactly that we will do look-ahead
here. we don't guarantee order of evaluation
The implication is that we can only provide advanced PRE_LAST
style blocks (or their equiv.) on the Cforeach loop. The fact
that they are impossible on the Cwhile loop should not
constrain our thinking for the Cforeach loop.
Just checking here: is PRE_LAST a separate and non-mutually
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
On Thu, 2002-05-09 at 13:22, David Whipp wrote:
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
what about
while (do_something_with_side_effects_and_check_still_ok()) {
I presume we don't want to do look-ahead here.
Yes, I think he was saying exactly that we will do
On Thu, 2002-05-09 at 12:37, David Wheeler wrote:
On 5/8/02 1:24 PM, Damian Conway [EMAIL PROTECTED] claimed:
Yes.
If you write:
class Foo {
my $.bar;
my $.baz is public;
...
}
you get a private C.bar() accessor and a public C.baz accessor.
What if I want my
while getNextValue() - $i {
...
}
while getOtherNextValue() - $i {
...
}
which generates no warning because each C$i is a parameter of the
corresponding loop block, and hence scoped to that block.
Ok, now I understand the plan. In brief, in the following example $result
is scoped to
Aaron Sherman wrote:
What if I want my methods to be called C.get_bar() and C.set_bar(),
since a certain Perl OO specialist suggests this approach is best for
avoiding ambiguity in one's API?
Then you can declare them as such:
sub get_bar() { .bar }
sub get_baz() { .baz }
Ok, now I understand the plan. In brief, in the following example $result
is scoped to the block that encloses the whole loop:
while (my $res = $search-getnext) { ...}
Yes. Because it's a lexical variable declared outside the closure controlled
by the Cwhile.
However, in the next
