HaloO,
I'll just use what Paul Seamons wrote:
Consider:
method foo {
.do_one_thing
.and_another_thing
map { $_.do_something_with( .bar ) } .items;
# .bar worked on the invocant - not the items
.and_the_last_thing
}
because I don't have to invent
Piers Cawley writes:
Larry Wall [EMAIL PROTECTED] writes:
I've been thinking about this in my sleep, and at the moment I think
I'd rather keep .foo meaning $_.foo, but break the automatic binding
of the invocant to $_. Instead of that, I'd like to see a really,
really short alias for
Luke Palmer skribis 2005-03-29 6:14 (-0700):
method iterate () {
for (@.objs) {
.process($_); # oops
}
}
There is an alarming similarity with
for (@hashes) {
.process($_)
}
Which doesn't quite use $self! ., .[], .{} are method calls,
On Tue, Mar 29, 2005 at 06:38:31PM +0200, Juerd wrote:
(B: Luke Palmer skribis 2005-03-29 6:14 (-0700):
(B: method iterate () {
(B: for (@.objs) {
(B: .process($_); # oops
(B: }
(B: }
(B:
(B: There is an alarming similarity with
(B:
(B:
On Tue, 2005-03-29 at 11:38, Juerd wrote:
Luke Palmer skribis 2005-03-29 6:14 (-0700):
method iterate () {
for (@.objs) {
.process($_); # oops
}
}
[...]
$_ is the topic, and I think that if we have two topics, Perl gets as
convoluted as Japanese
Larry Wall skribis 2005-03-29 9:27 (-0800):
and write _.method, which is of dubious merit. Or we could use `,
`[], `(), and `method if we don't use ` for qx. I daresay `method
would probably be used more than qx for many styles of programming.
Hey, look at that, backticks again :)
If the
Paul Seamons wrote:
To sum up...
If you are in a method then you get .method and it always works even if $_ is
rebound to something else.
I also have problems to perceive .method beeing bound to $_ from a
typing point of view: $_ is a dynamic variable in the runtime
environment, while the method
Larry Wall [EMAIL PROTECTED] writes:
I've been thinking about this in my sleep, and at the moment I think
I'd rather keep .foo meaning $_.foo, but break the automatic binding
of the invocant to $_. Instead of that, I'd like to see a really,
really short alias for $self. Suppose we pick o
At the moment I'm trying to see if I could get used to ..method meaning
$_.method, and whether it buys me anything psychologically.
At some point, adding another thing people have to remember in order to
save one character gets a bit self-defeating, surely.
The good thing about $_.method is
On Fri, 18 Mar 2005 09:45:57 -0800, Larry Wall wrote:
I think we'll need to figure out how to shorten $_.foo instead.
It looks short enough to me already. More importantly, its meaning
is immediately obvious.
Either that, or there has to be a way to explicitly make $_ the
invocant of a
On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
: What it doesn't solve is the $.method vs .method issue. They look
similar
: but one works on the invocant and one works on $_. Still a trap.
Yes, and that's probably the killer of the oc idea. So much for
Sleep Brain, heh,
On Thu, Mar 17, 2005 at 11:46:52PM +0200, Yuval Kogman wrote:
I think this should mean $_, and if the user really really really
wants to do .foo on the invocant, then why not just say:
method bar ($_:) {
.foo;
}
Because $_ can change.
method bar ($_:) {
[ Sorry if my replies to this thread have seemed a little disjoint. I just
realized I'd unsubscribed myself from p6l last year when I started a $job$
and never resubscribed. So I'd only been seeing fragments of the
conversation. Catching up from the archives...
]
Larry's idea of making
Michael G Schwern skribis 2005-03-17 14:42 (-0800):
Because $_ can change.
method bar ($_:) {
.foo;
map { .baz } 1..10; # whoops
}
The problem here is not specific to methods.
It is generic to all nested uses $_. We used to see this mostly with
Right. I believe the times one will want to do a method call on $_ when it
is *not* the invocant will be greatly outnumbered by the times when you
want to do a method call on the invocant. Thus adding ambiguity to .method
is not worth it.
I think this boils it all down nicely. It seems
On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote:
: What it doesn't solve is the $.method vs .method issue. They look similar
: but one works on the invocant and one works on $_. Still a trap.
Yes, and that's probably the killer of the oc idea. So much for
Sleep Brain, heh,
There's a discussion going on #perl6/irc.freenode.org right now wondering
about what .method means. We'd all assumed it meant $self.method (where
$self is always the method invocant) but then had a look at Synopsis 12
which states
Dot notation can omit the invocant if it's in $_:
I should add that Darren and I, who both have similar tendencies towards
larger scale coding where consistency is far preferred to compactness,
both ended up concluding that our style policies will be to _always_ use
explicit invocants (except of course for one liners).
In the case of the
That is correct. It probably should have read ...our style policies
will be to _always_ use explicit invocants, if .foo ends up meaning
$_.foo in the final release (as it does now).
(of course, I suspect Darren will keep using them anyways, but then he
likes to be even more explicit than I am)
On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote:
I should add that Darren and I, who both have similar tendencies towards
larger scale coding where consistency is far preferred to compactness,
both ended up concluding that our style policies will be to _always_ use
explicit
Larry Wall writes:
In that case we'd have to say that given and for always require
- $x inside methods, and that $x is never automatically aliased to
$_. But there are other ramifications with switch statements and
exception handlers I have to think through,
In particular, the fact that
$self.method or $_.method.
Anyhow, I don't see why not. :)
Autrijus Tang wrote:
Luke Palmer wrote:
And it would be a shame to disallow the use of $_ in map.
Err, wait, I don't think we are discussing whether $_ is to
be outlawed in map {}.
Perhaps we should consider making $_ readonly in map and grep?
--
Garrett Goebel
IS Development
Garrett Goebel skribis 2005-03-17 8:37 (-0600):
Perhaps we should consider making $_ readonly in map and grep?
That's one way to avoid clever tricks. Please let's not.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
I've been thinking about this in my sleep, and at the moment I think
I'd rather keep .foo meaning $_.foo, but break the automatic binding
of the invocant to $_. Instead of that, I'd like to see a really,
really short alias for $self. Suppose we pick o for that, short
for object. Then we get
On Thu, 17 Mar 2005, Larry Wall wrote:
really short alias for $self. Suppose we pick o for that, short
for object. Then we get self calls of the form:
o.frobme(...)
How 'bout ..frobme(...)? Or would it be a hell to tell from C..?
(Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy,
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote:
: Then we get self calls of the form:
:
: o.frobme(...)
Sleep Brain would also like to point out that this lets you use o
standalone when you want to pass the current object as an ordinary
argument to some other class. Likewise for
On Thu, Mar 17, 2005 at 05:52:15PM +0100, Michele Dondi wrote:
: On Thu, 17 Mar 2005, Larry Wall wrote:
:
: really short alias for $self. Suppose we pick o for that, short
: for object. Then we get self calls of the form:
:
:o.frobme(...)
:
: How 'bout ..frobme(...)? Or would it be a hell
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote:
I've been thinking about this in my sleep, and at the moment I think
I'd rather keep .foo meaning $_.foo, but break the automatic binding
of the invocant to $_. Instead of that, I'd like to see a really,
really short alias for $self.
On Thu, 17 Mar 2005, Larry Wall wrote:
:o.frobme(...)
:
: How 'bout ..frobme(...)? Or would it be a hell to tell from C..?
: (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!)
:
: How 'bout a single underscore? _.frobme()?!?
Thought about those in the night, but they don't
I think this should mean $_, and if the user really really really
wants to do .foo on the invocant, then why not just say:
method bar ($_:) {
.foo;
}
This keeps $_ unambiguosly the 'it', while 'this' is more specific.
Think:
it puts the lotion on the skin
method blah {
31 matches
Mail list logo
