> 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 C.
> However, in the next exa
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
> 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
i
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> access
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
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
> The implication is that we can only provide advanced "PRE_LAST"
> style blocks (or their equiv.) on the C loop. The fact
> that they are impossible on the C loop should not
> constrain our thinking for the C loop.
Just checking here: is PRE_LAST a separate and non-mutually exclusive
concept fro
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
