RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
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 is exactly saying
that, no?
As the he refered to, let me be absolutely clear that I am
*not* suggesting any type of look-ahead here. I was specifically
talking about the Cforeach loop, where Perl is expected to
implement the iterator. In a Cwhile loop, the programmer
controls the iterator, and would be surprised by a loop-ahead.
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.
Dave.
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
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 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?
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.
-Miko
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
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. Cwhile and Cforeach are
not synonyms. They have distinct characters.
To me, the concept of PRE_LAST makes sense in the context of
Cforeach, and is easy to implement. In the case of a Cwhile,
or Cloop 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.
RE: FIRST, BETWEEN, etc.. (was Re: Loop controls)
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 look-ahead
here. we don't guarantee order of evaluation is exactly saying
that, no?
As the he refered to, let me be absolutely clear that I am
*not* suggesting any type of look-ahead here. I was specifically
talking about the Cforeach loop, where Perl is expected to
implement the iterator. In a Cwhile loop, the programmer
controls the iterator, and would be surprised by a loop-ahead.
My bad. Missed the transition from foreach to while... oops!
Re: Accessor methods ?
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 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 }
sub set_baz($newbaz) { .baz = $newbaz }
I suppose there could be some magic like:
class Foo is accessedby('get_','','r')
is accessedby('set_','','rw') { ... }
To declare that Foo has accessors with prefix get_ and no suffix for
read-only acces and prefix set_ and no suffix for read/write access.
But, I'm not sure how valuable this would be
Re: Loop controls
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 the block that encloses the whole loop:
while (my $res = $search-getnext) { ...}
However, in the next example, $res is scoped to the loop:
while $search-getnext() - $res { ...}
Right? OK, that sounds cool. We still have loop-scoped variables. I'd
like to suggest, though, that the first example would refuse to compile. If
the plan is to significantly change the behavior of something as popular as
that construct (and I did some research, it's VERY popular, details
available on request), it would make more sense to refuse to compile than to
DWIDM (Do What I Don't Mean).
-Miko
Re: Accessor methods ?
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 }
sub set_baz($newbaz) { .baz = $newbaz }
Close. They'd probably be implemented like this:
method get_bar() { $.bar }
method get_baz() { $.baz }
method set_baz($newbaz) { $.baz = $newbaz }
Of course, there would need to be some way of simultaneously preventing the
automagic creation of accessors. That might be manual:
class Foo {
my $.bar;
my $.baz;
method bar is private {}
method baz is private {}
...
}
or per-attribute:
class Foo {
my $.bar is accessorless;
my $.baz is accessorless;
...
}
or (my favorite) global:
class Foo {
no accessors;
my $.bar;
my $.baz;
...
}
Damian
I suppose there could be some magic like:
class Foo is accessedby('get_','','r')
is accessedby('set_','','rw') { ... }
To declare that Foo has accessors with prefix get_ and no suffix for
read-only acces and prefix set_ and no suffix for read/write access.
But, I'm not sure how valuable this would be
Re: Loop controls
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 example, $res is scoped to the loop:
while $search-getnext() - $res { ...}
Yes. Because it's a parameter of the closure controlled by the Cwhile.
Right? OK, that sounds cool. We still have loop-scoped variables. I'd
like to suggest, though, that the first example would refuse to compile.
I don't think so.
If the plan is to significantly change the behavior of something as popular as
that construct (and I did some research, it's VERY popular, details
available on request), it would make more sense to refuse to compile than to
DWIDM (Do What I Don't Mean).
H. By the same argument we should refuse to compile the very popular
C$var[$idx] and C$var{key} constructs, since they no longer mean what
they meant in Perl 5.
I don't think that's the right answer. A construct like:
while (my $res = $search-getnext) { ...}
has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
reasonable than in Perl 5.
However, Miko has highlighted a genuine transition problem, and one might imagine
something like:
use warnings 'P52P6';
that would point out potential problems like this.
Damian
