Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Austin Hastings wrote:
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses topic to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if Cfor changes topic, then what?
OUTER::.:send_one($_);
Yuck.
I believe it needs to be
method send ($self: [EMAIL PROTECTED]) {
$self.:send_one(BEGIN);
for @data {
$self.:send_one($_);
}
$self.:send_one(END);
}
While that works (I think it works anyway), its debatable if it's nice
or not. The first and last calls to .:send_one shouldn't need the $self,
but I put it there because if you use the $self inside the for in a
method that short, it's nice and clear to have it outside it as well.
I suspect the original example expands the for loop into the equivalent of:
for @data - $item {
$item.:send_one($item);
}
And it doesn't take a $larry to figure out that this isn't going to make
the compiler very happy, as it's most likely a violation of class access
control, I would have thought.
So Luke, am I right?
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Larry Wall writes:
Currently it does. There have been some rumblings in the design team
that maybe it shouldn't. But it occurs to me that this might be another
spot to have our cake and eat it to. We could say that
for @foo - $input { ... $input ... }
doesn't set the topic in the block by default. However, methods do set
the topic (though there have been rumblings about that too). So we could
simply say that pointy subs can also be pointy methods if you specify
an invocant:
for @foo - $input: { ... $input and $_ ... }
I think I like that, but it needs to be thunk about some more. The downside
is that it's rather subtle. The upside is that it falls out of existing
rules, and lets - map more naturally in the way people expect. I don't
think people will naturally expect - to clobber $_.
Considering that I was the rumbler, I'll try to stay concise. Don't
think that this is anything more than a stormy brain, though.
I really like the fact that for always topicalizes. I like it because
it forces refactors where they ought to be happening. I always get
confused when I see:
for (@array) {
for my $row (@{$data-[$_]}) {
for my $element (@$row) {
foobar($_) if $element;
}
}
}
It works that way in natural languages too. If you try to use it too
remotely, you just confuse everybody. In particular:
For each element in @array, look up the corresponding $row in $data,
and for each $element in the $row, call foobar on it if $element is
true.
Call foobar on what?
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Luke
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote:
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using oper on the elems anymore.
method perform (oper) {
for @.elems {
oper($_);
}
}
But I don't think that was the mistake you were talking about. And I
don't see what it has to do with unary dot either, because you don't
need to use unary dot to implement that method. Unless each member of
@.elems is a Duple, in which case the class isn't one I'd call Tuple.
Sorry, nitpicking level seems to be set to 9 at the moment. What did you
mean?
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Matthew Walton writes:
Luke Palmer wrote:
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using oper on the elems anymore.
That's mostly because I really screwed up the example. Mind, it was
very, very early in the morning when I wrote this. Let's try again.
(This is a pretty trivial example, but the problem only gets worse as we
approach real life).
class MyStream {
has $.stream;
method :send_one ($item) {
$.stream.send($item);
}
method send ([EMAIL PROTECTED]) {
.:send_one(BEGIN);
for @data {
.:send_one($_);
}
.:send_one(END);
}
}
Luke
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote:
class MyStream {
has $.stream;
method :send_one ($item) {
$.stream.send($item);
}
method send ([EMAIL PROTECTED]) {
.:send_one(BEGIN);
for @data {
.:send_one($_);
}
.:send_one(END);
}
}
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses topic to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if Cfor changes topic, then what?
OUTER::.:send_one($_);
Yuck.
=Austin
