Re: .method == $self.method or $_.method?
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 examples on my own---thanks Paul!
My idea is to steal the postfix : from labels and use a keyword there.
I propose 'land', which nicely fits 'goto hell' with 'land hell'.
But linguistics is Larry's department. Actually these might be just
be yet another control flow pair.
Then the above example could become:
BTW: don't the statements need termination/separation with semicolon?
method foo
{
.do_one_thing;
.and_another_thing;
map { do_something_with: .bar } .items;
# .bar worked on the invocant - not the items
# map { do_something_with $_: $invocant.bar } .items
.and_the_last_thing # here semicolon is optional
}
the absence of . in front of do_something_with is easily spotted by an
eye trained to Perl6 method code while the same applies to the : which
indicates an indirect object and thus syntactically linked to the dynamic
dispatcher.
It seems that the oc behavior and the .method acts on $_ are huffmanized
the wrong direction.
Hmm, outside of methods .method is just an operator that can be parsed
generically---without declaration that is. So dot to me is the method
sigil:
methodmeans closure variable
$methodmeans variable
.methodmeans postfix operator (needs explicit lhs)
.$method means operator ref (e.g. $method = postfix:++)
method:means method call with $_ passed in as invocant
$method: same via method ref
method means predeclared sub/multi call (or generic listop?)
method() same
method $x: indirect object syntax meaning $x.method
In method scope no invocant is needed as lhs because it is the invocant:
$.method means public instance variable (from lexical class environment)
.methodmeans public method on invocant
.$method means public method ref on invocant
$:method means private instance variable
:methodmeans private method on invocant
:$method means private method ref on invocant
The more I think about it the more I think the current behavior of .method on
$_ is wrong. I don't think you should be able to dynamically set the
invocant. Consider the danger of:
method foo {
some_sub_bar();
.do_something();
I agree. If the programmer of the method wants to dispatch do_something
as usual she could leave out the dot. But whatever happens in there it
should not be able to modify the method's invocant.
BTW, is there a $?SELF for methods and @?SELF for multi methods?
And are the following multi calls:
($x, $y, $z).multimethod;
@array.multimethod; # might interfere with container methods
or is that syntax too weird?
# this now does get_some_other_object.do_something()
}
Of course do_something() could change $_ but that is no surprise.
The invocant variable is off-limits. In an abstract sense a method
is not mutating it's self but rebinds the value that $?SELF is
referring to.
As a side effect of not binding $_ to the invocant, the method
can easily check if it was invoked on the topic with $_ =:= $?SELF
--- Wait a moment, are you talking about me?.
Regards,
--
TSa (Thomas Sandlaß)
Re: .method == $self.method or $_.method?
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 $self. Suppose we pick o for that, short
for object. Then we get self calls of the form:
o.frobme(...)
I really, really don't want to see .foo meaning anything but $_.foo, so how
about arranging things so that the invocant becomes $_ iff you don't give it a
name.
The problem with that is that people start learning that .foo means call
foo on the current object, and then they write:
method iterate () {
for (@.objs) {
.process($_); # oops
}
}
And they may even know the rule, but $_ is a hard thing to get used to
in Perl. I think it's best is call a method on the current object
looks the same everywhere it is used.
Luke
Re: .method == $self.method or $_.method?
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, visually,
and should act on the same thing as their unbracketed dot friends.
Subscripting an object is bad style, so $_ for that really is the better
option, I think.
$_ is the topic, and I think that if we have two topics, Perl gets as
convoluted as Japanese for someone who doesn't understand the language.
With loop constructs, the idiomatic syntax for getting a non-$_ is
- $foo, and a similar thing can be done with methods: ($foo:).
But please, let's have a single topic, and let that always be $_. If you
want to access an outer $_, that's $OUTER::_, or its alias, $foo. Just
like everywhere else in Perl. This consistency makes it easy to learn
and easy to debug when it bites.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: .method == $self.method or $_.method?
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: for (@hashes) {
(B: .process($_)
(B: }
(B:
(B: Which doesn't quite use $self! ., .[], .{} are method calls, visually,
(B: and should act on the same thing as their unbracketed dot friends.
(B
(BThat only saves one character over this:
(B
(Bfor (@hashes) {
(B$_process($_)
(B}
(B
(B: Subscripting an object is bad style, so $_ for that really is the better
(B: option, I think.
(B
(BThe alternative is for ., .[], and .() to be illegal on objects
(Bthat don't support those roles. Well, okay, there's yet another
(Balternative, which is that these operators are spelled wrong, and that
(Bwe're abusing the idea of . to make it mean too many other things,
(Blike "eat the whitespace before this if it would look like a binary
(Boperator." Maybe these are actually spelled _, _[], and _() in
(Btheir long form. Have to think about that some. But using _ instead
(Bof . would more naturally lend itself to defaulting to $_, I think.
(BThe main problem is it doesn't help shorten $_.method. But maybe
(Bthat's a feature. Doutless someone will define term _ to mean $_
(Band write _.method, which is of dubious merit. Or we could use `,
(B`[], `(), and `method if we don't use ` for qx. I daresay `method
(Bwould probably be used more than qx for many styles of programming.
(B
(B: $_ is the topic, and I think that if we have two topics, Perl gets as
(B: convoluted as Japanese for someone who doesn't understand the language.
(B
$B$=$&(B $B$G$9(B $B$M(B...
(B
(B: With loop constructs, the idiomatic syntax for getting a non-$_ is
(B: "- $foo", and a similar thing can be done with methods: "($foo:)".
(B:
(B: But please, let's have a single topic, and let that always be $_. If you
(B: want to access an outer $_, that's $OUTER::_, or its alias, $foo. Just
(B: like everywhere else in Perl. This consistency makes it easy to learn
(B: and easy to debug when it bites.
(B
(BThere will certainly be a single topic. The only question is whether .
(Bwill ever default to it. I'm still leaning not.
(B
(BLarry
Re: .method == $self.method or $_.method?
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 for someone who doesn't understand the language.
I've put a lot of thought into this one since topics were first
broached. It's been nagging at me, and I think I see a solution.
Use given as a statement (not a block control operator):
given :invocant;
This binds $_ to the current invocant.
given 1;
given maintains a stack (which, itself is lexically scoped, so you don't
get to reach into a caller's givens), so here we request the 1th
(zero-indexed, of course) context.
If we call given's stack @_given, then the above statement is just:
$_ := @_given[1];
Any implicit binding of $_ other than through the use of given inserts
the new value into the stack, so you can do:
given 1;
given 0;
given 1;
Without changing the given stack (important for maintainable code).
This is distinct from:
given 1 { ... }
In which we bind $_ to the number 1.
This also works with labels:
OUT: for @a {
IN: for @b {
given OUT; say Outer scope {$_};
given IN; say Inner scope {$_};
}
}
by determining the @_given entry that was active in the given scope (ok,
so @_given actually contains more information than just the value
itself).
It would be potentially interesting to introduce a give keyword for
this purpose:
map {map {give 1} 0..1000} @foo;
which simply returns the value of {given 1;$_}
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: .method == $self.method or $_.method?
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 community rejected %hash`key because it was ugly (I still disagree), then will it accept `keys to mean $_.keys? And doesn't consistency want %hash`keys to be as valid as %hash.keys, then? That's dangerously close to %hash`key, even though it means something else. ?$B$=$ ?$B$G$9 ?$B$M... Hmm... (Someone translate this for me, please :)) There will certainly be a single topic. The only question is whether . will ever default to it. Any defaulting to a variable that isn't $_ practically introduces a 2nd/Nth topic, even if it isn't officially called topic. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: .method == $self.method or $_.method?
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 is compiled in a class' scope. From type theory a class should be understood as a type generator with its $?CLASS as an implicit parameter. That means in subclasses the invocant has the subclass type even when the method is not redefined. That's basically a complicated way to say that all methods in Perl6 are virtual in the C++ sense ;) So every .method would be bound to an invocant of the class type at compile time! At that time there is no implicit $_ yet. And the set of methods should be known to the compiler, BTW. I even doubt the usefullness of $_ in methods: it's way too far away from the (runtime) context. After all, OOP is about dealing with the class and parameter environment in methods only, and it's easy to grep the topic by means of the 'is topic' parameter trait---and call the variable $_ if wanted. Only in code that is outside of classes---that is subs and top level statements (what about rules?)---method calls are compiled such that they are invoked on $_ and the only question is if this usage might be written without explicit $_ or if this is too easily mixed with class coding. But I think that a programmer knows if he's in method scope or not. OTOH, copy and paste of lines might change meaning without the compiler having a chance to detect it! -- TSa (Thomas Sandlaß)
Re: .method == $self.method or $_.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 for that, short
for object. Then we get self calls of the form:
o.frobme(...)
I really, really don't want to see .foo meaning anything but $_.foo, so how
about arranging things so that the invocant becomes $_ iff you don't give it a
name. So:
method whatever {
# $_ is whatever's invocant
}
method whosit ($self:) {
# $_ is unbound, so:
.this # fails
...
}
Note that this would also work for mappy things with pointy subs used to name
arguments.
method whatever {
map { .this } .list_of_contents; # Works, but is weird...
map - $x { .do_something_with($x.result) } # .do_something uses the
# method's invocant.
}
Same applies to given:
method foo {
given .parent - $p {
... # $_ is foo's invocant
}
given .parent {
... # $_ is the result of calling .parent
}
}
Re: .method == $self.method or $_.method?
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 that it is familiar, quite compact
anyways by virtue of using $_, and nobody is going to be surprised by it.
Personally (and I'm admittedly leaning towards simplicity lately) I'd
even throw a warning for using .method when there is an explicitly named
invocant as well.
# Good
sub foo {
.bar;
}
# Possibly confusing, throw a warning or forbid under strict?
sub foo ($self:) {
.bar;
}
# More obvious
sub foo ($self:) {
$self.bar;
}
of course, since it is still preferable to be symmetrical, if $.attr is
legal (and no warning) with a named invocant, then so should .method be.
Adam K
Re: .method == $self.method or $_.method?
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 subblock.
How about something like this?
method foo{
.bar; # Acts on self
for @stuff {
.bar; # Acts on self
}
for @stuff - $_ :self {
.bar; # Acts on self, which is currently $_
}
}
Seems like overkill for trivial blocks though:
map - $_ :self { .bar } 1..10;
but you can still just write $_.bar
Maybe we could allow $_ to be elided?
map - :self { .bar } 1..10;
At the moment I'm trying to see if I could get used to ..method
meaning $_.method, and whether it buys me anything psychologically.
I still prefer $_.method
Suppose you are one of those rare people who actually checks the
return value of print to see if you filled up the disk:
if print {...}
That doesn't parse currently ... (Backtracking the parser is
probably not the right answer.)
If you're going to the trouble to check that (which I do,
sometimes), surely two extra characters [$_ or ()] aren't that
much of a problem? You probably wouldn't be using implicit
variables, anyway.
A backtracking parser seems pretty scary to me. If it takes a lot of
work for the compiler to figure things out, it's going to be even
harder for the programmer.
--
Peter Haworth [EMAIL PROTECTED]
I think this is one of those traumatic things eggs have to face
to prepare a good omelette.
-- Jarkko Hietaniemi
Re: .method == $self.method or $_.method?
Larry Wall kirjoitti: 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, heh. I think we'll need to figure out how to shorten $_.foo instead. Either that, or there has to be a way to explicitly make $_ the invocant of a subblock. What about using the oc idea to shorten $_.foo x.foo (or some other letter instead of 'x') Still this only shortens it by one char... (Not sure if I like this at all - just an idea...) -- Markus Laire Jam. 1:5-6
Re: .method == $self.method or $_.method?
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, heh. I think we'll need to figure out how to shorten $_.foo instead. Either that, or there has to be a way to explicitly make $_ the invocant of a subblock. What about using the oc idea to shorten $_.foo x.foo How about t.foo --- t for topic? ;-) Nige
Re: .method == $self.method or $_.method?
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 ($_:) {
.foo;
map { .baz } 1..10; # whoops
}
This keeps $_ unambiguosly the 'it', while 'this' is more specific.
I'm not proposing changing what $_ means, I'm proposing changing what .method
means. Instead of $_.method make it mean $invocant.method. Sooo I'm not
really sure where all that extra stuff about $_ was going, true as it may be.
Perhaps i'm sort of forcing this distinction.
However, I wouldn't be too happy with having to do this, though:
method data {
map { $OUTER::_.process($_) } .things;
}
or having to name the invocant every time I want to map {}.
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.
Lastly, what is wrong with
$.method?
As I understand it, $invocant.method and $.method are different. The first
is a public attribute the second is a method call, no? And while all
attributes have an associated method (as I understand, ie. foreach $.foo,
$invocant.foo should always be the same) the reverse is not true.
Foreach $invocant.foo there need not be a $.foo.
If this assumption is incorrect then my argument does collapse.
Re: .method == $self.method or $_.method?
This drifed off list but I don't think that was intentional.
- Forwarded message from Yuval Kogman [EMAIL PROTECTED] -
From: Yuval Kogman [EMAIL PROTECTED]
Date: Fri, 18 Mar 2005 01:12:42 +0200
To: Michael G Schwern [EMAIL PROTECTED]
Subject: Re: .method == $self.method or $_.method?
User-Agent: Mutt/1.5.6i
On Thu, Mar 17, 2005 at 14:42:06 -0800, Michael G Schwern wrote:
Because $_ can change.
method bar ($_:) {
.foo;
map { .baz } 1..10; # whoops
}
I don't see it as a whoops. It's either or, and the user gets to
choose.
I read that as:
method bar ($self:) { for ($self) {
...
}}
BTW, given:
method bar {
# what's $self named in here?
# do you need to name it for it to be accessible?
}
S12 does not specify, as far as I can tell.
Perhaps the desired behavior could be: If the invocant is not
specified it is the default, i.e
method bar {
}
is really
method bar ($_:) {
}
and the user assumes responsibility for not resetting $_ if they
would like to keep it.
As I understand it, $invocant.method and $.method are different. The first
is a public attribute the second is a method call, no? And while all
attributes have an associated method (as I understand, ie. foreach $.foo,
$invocant.foo should always be the same) the reverse is not true.
Foreach $invocant.foo there need not be a $.foo.
I think you are right... But here is an idea:
The only conflict I see with the reverse not being true is if you
would like to avoid calling the is rw accessor when you want to set
the attribute from within the class.
This assumes that $.attribute = ... from within an accessor means
the attribute itself, as a special case, and that all accessors are
rw when their caller is eq ::?CLASS.
Again, the problem is that an accessor that is rw and does funny
stuff to it's attribute could not be avoided when a sibling method
wants to just fudge the attribute.
On second thought, this problem seems bigger now. Opinions?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me beats up some cheese: neeyah!
- End forwarded message -
--
Re: .method == $self.method or $_.method?
[ 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 $_ == $self in methods seems to swing the pendulum the other way. Now its a shame to have to make everything explicit inside map, grep, and short for loops etc... And yes, what about given? My immediate reaction to o.method and c.method was a little bit of the heebie-jeebies but then I remembered hey, I wrote CLASS.pm so I could do CLASS-method and its exactly the same thing, a constant function which returns the name of the class. Then c.method doesn't seem so weird. And if you want to be crazy I suppose you can define your own c() and o() functions. :) Its shorter than $self.method and it solves the $_ ambiguity problem so that's good. Its a shame to lose the even shorter .method for an extremely common task but I'm not going to quibble to much over a single character. 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.
Re: .method == $self.method or $_.method?
Err, wait, I don't think we are discussing whether $_ is to be outlawed
in map {}. I think the proposal is for .method always mean $invocant.method
and make it illegal when there is no invocants in sight, mush as $.attr
would be illegal without an invocant. To use $_.foo, write $_.foo.
Luke is discussing flow-on effects, just as larry was with his 'o' and 'c'.
if ( .process is $_.process ) {
either {
Specify an explicit invocant --- Larry
} or {
Specify an explicit topical variable --- Luke's musing
}
} else {
Call methods on $_ using $_.method --- My preference still :)
}
The only thing that worries me about The OC idea (how curious that a
feature is so easily named after a TV show) is that he is talking about
them being functions. I don't know enough about interals, but would that
get optimised to something faster, or do we suffer a second function
call every time we want to call a method?
I also have some worries about there being three different ways to call
a simple invocant method.
.method
$_.method (except in map/grep)
o.method
It has a faintly similar smell to the workaround-hell mod_perl 2 got
into... I'm all for TMTOWDTI, but surely the language should be elegant
enough that something as simple as calling a not-special-in-any-way
method doesn't need to have three different ways to do it?
An interesting exercise for anyone with a minicpan checkout would be to
scan CPAN and see how often the various uses are needed currently.
($self- compared to $_-).
Granted there are a hell of a lot of caveats in that, but it there's a
10 to 1 ratio of one to the other, surely that would help to make the
prefered preference a little clearer?
Adam K
Re: .method == $self.method or $_.method?
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
nested foreaches, but now we get methods too.
The solution is also generic for all these situations: either use
$OUTER::_ or give the outer $_ another (second) name.
This is consistent, easy to learn and easy to work around, especially
now that Perl has an easy syntax for aliasing.
I'm not proposing changing what $_ means, I'm proposing changing what .method
means. Instead of $_.method make it mean $invocant.method. Sooo I'm not
really sure where all that extra stuff about $_ was going, true as it may be.
That will be very weird if you still want .foo to work on $_. The same
prefix operator will then have two possible implied invocants. I think
of as a postfix *method* rather than an operator, and would want this
to be consistent.
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 don't believe this, especially because I read subscripting as methods.
Isn't the whole problem solved by using dotless syntax for calling a
method on the current invocant? If calling methods on the invocant is
indeed more common, then Huffman will like this. I haven't looked into
possible clashing with subs/multis yet.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: .method == $self.method or $_.method?
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 more important to have
consistency on what .method does. I think it should stay bound to the
invocant and should die/warn if there is none. There are so many almost
short ways to call methods on the current topic of grep or map that it seems
a shame to mess up the consistency of .method just to remove a few
characters.
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
}
method foo {
.do_one_thing
.and_another_thing
map { $^item.do_something_with( .bar ) } .items;
.and_the_last_thing
}
Both of those feel clean to me as opposed to
method foo {
o.do_one_thing
o.and_another_thing
map { .do_something_with( o.bar ) } o.items;
o.and_the_last_thing
}
Now granted - that the o. isn't the worst thing to look at. It still seems
harder to follow what is calling which method - you sort of have to deduce
that since the do_something_with call doesn't begin o and because you are in
a map then it must be behaving on the topic $_ even though $_ isn't in sight.
We have added a nother level of details (arguably ambiguity) to try and clear
up some ambiguity.
With the former methods it is clear and consistent which methods are being
called on which variables. The .method doesn't change mid method and I know
what variable is calling do_something_with because it is spelled out.
It seems that the oc behavior and the .method acts on $_ are huffmanized
the wrong direction.
Now with an object in non-method we have with .method only on invocant we
have:
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { $_.do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
sub foo {
map { .do_something_with() } get_items();
# dies because there is no invocant
}
and with the .method uses $_ we have
sub foo {
my Foo $o = get_object();
$o.do_one_thing
$o.and_another_thing
map { .do_something_with( $o.bar ) } $o.items;
$o.and_the_last_thing
}
We haven't really won anything other than dropping a few characters.
As I was thinking about that I began wondering if it was possible to
dynamically specify what the invocant is. Wouldn't you know it? That is
what $_ does currently - except you only get .methods, not $.properties.
The more I think about it the more I think the current behavior of .method on
$_ is wrong. I don't think you should be able to dynamically set the
invocant. Consider the danger of:
method foo {
some_sub_bar();
.do_something();
# this now does get_some_other_object.do_something()
}
sub some_sub_bar {
$CALLER::_ = get_some_other_object();
}
That is kind of scary if call to another sub can hijack my method calls (I'm
sure there are other ways to hijack the method calls - but having the
invocant dynamically set offers too many dangers). Maybe it isn't possible
because $_ will be r only - but somehow I think $_ is rw and the invocant is
r only.
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 think that the idea of $_ default to the invocant is necessary and good but
the mistake comes in inferring that .method then must work on $_.
.method should work on the invocant period - it just happens to be a
coincidence that $_ is the same as the invocant for most of the time.
Paul Seamons
I'll go back to lurking about now.
Re: .method == $self.method or $_.method?
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, heh. I think we'll need to figure out how to
shorten $_.foo instead. Either that, or there has to be a way to
explicitly make $_ the invocant of a subblock.
At the moment I'm trying to see if I could get used to ..method meaning
$_.method, and whether it buys me anything psychologically. Also, how
much of this could be solved with functions that merely default to $_
as in Perl 5? Why do .print if we can say print? (It's not a
rhetorical question, since, .print doesn't look for another argument
in the absence of parens, and print does, which could try to slurp
up a following block. Suppose you are one of those rare people who
actually checks the return value of print to see if you filled up
the disk:
if print {...}
That doesn't parse currently, because the print will treat {...}
as a closure argument and then there's no block for the if.
(Backtracking the parser is probably not the right answer.)
Larry
.method == $self.method or $_.method?
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 $_: .doit(1,2,3) This seems to cripple .method's usefulness by coupling it to $_ which can change often. Now in order to be safe for anything but trivial methods you're back to writing out $self all over the place, something that Perl 6 was supposed to fix about Perl 5. It has also been pointed out that .foo, $.foo, @.foo and %.foo are all (intentionally) similar and all but one operates on the invocant. Only .foo operates on $_. This seems like a newbie trap waiting to happen. MOST of the time .foo will work like $self.foo but every once in a while they'll get caught in a gotcha. Thoughts?
Re: .method == $self.method or $_.method?
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 Algorithm::Dependency module that is being ported
over as a test, and given that larger chunks of code have a tendency
towards named iterators in loops anyways, and we've ended up with the
only sane way to be the wordiest of the various ways-to-do-it.
Just for the record, I for one would have much preferred to have .foo be
the same as $.foo and @.foo and %.foo and refer to the invocant method,
at the cost of using C map { $_.foo } .
To describe it in emotional terms, the current situation feels
backwards and inside out.
Adam K
Michael G Schwern wrote:
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 $_:
.doit(1,2,3)
This seems to cripple .method's usefulness by coupling it to $_ which
can change often. Now in order to be safe for anything but trivial methods
you're back to writing out $self all over the place, something that Perl 6
was supposed to fix about Perl 5.
It has also been pointed out that .foo, $.foo, @.foo and %.foo are all
(intentionally) similar and all but one operates on the invocant. Only
.foo operates on $_. This seems like a newbie trap waiting to happen.
MOST of the time .foo will work like $self.foo but every once in a while
they'll get caught in a gotcha.
Thoughts?
Re: .method == $self.method or $_.method?
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) :) Personally, .foo meaning $self.foo seems more consistent to my mind, and I'd happily standardise on implicit invocants. The only minor thing I can see would be that you will end up with a slight asymmetry question of if we use $:attribute for a private attribute, do we call :method for a private method? Adam K Michael G Schwern wrote: 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 invocants (except of course for one liners). I thought your conclusion was you'd only use an explicit invocant if .foo meant $_.foo. And to drop it if .foo means $self.foo as there's no ambiguity.
Re: .method == $self.method or $_.method?
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 invocants (except of course for one liners). I thought your conclusion was you'd only use an explicit invocant if .foo meant $_.foo. And to drop it if .foo means $self.foo as there's no ambiguity.
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote: : Personally, .foo meaning $self.foo seems more consistent to my mind, and : I'd happily standardise on implicit invocants. I'm thinking about it. There are definitely things to be said for both sides, and maybe we can come up with a solution that's better than what we have. And after all, I originally came up with the .foo notation precisely for the purpose of leaving out $self and still having it self-documenting, as it were. I have a vague feeling that the real linguistic thing going on here is that you shouldn't change the meaning of it within a method, so one possible solution would just be to prohibit any rebinding of $_ to anything other than the current object. 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, and I'm a slow thinker, and unfortunately I'm having to moonlight at a real job to put bread on the table and pay back all the money I've borrowed over the last several years in order to devote myself to Perl 6--so you'll all just have to be patient with me. Well, you don't have to, but it'd be nice... : The only minor thing I : can see would be that you will end up with a slight asymmetry question : of if we use $:attribute for a private attribute, do we call :method : for a private method? I think those would still be .:method, and we just live with the asymmetry, unless we decide there's sufficient declarational power in the class that we can always distinguish :method from :pairkey, which there might be. But even if there is, most uses of private methods will probably be from within trusted classes, and access to my own attributes through $:foo instead. Plus .:method doesn't require people to remember what's been declared to decide if it's a pair or a private method. Larry
Re: .method == $self.method or $_.method?
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 `map` rebinds $_. Consider:
method data () {
map { .process($_) } @.array;
}
Is that calling `$_.process($_)` for each `$_` in [EMAIL PROTECTED], or is it
calling `$self.process($_)`? It must be the former, which, given the
context, is probably not what was intended (despite the terrible (but
unfortunately, typical) naming, we can still tell what the programmer
was thinking). `.process` means something else everywhere else in the
method, and Perl goes to great lengths to keep it that way, but in this
case it's different.
And it would be a shame to disallow the use of $_ in map.
Disallowing one of the most beautiful areas of Perl, topicalization, in
methods would be irritating at best. Oh, so I can only program in a
crappy subset of Perl because I'm in a method? I don't know about the
other programmers here, but just about all my code is in methods.
Actually, scanning over my most recent module, *all* my code is in
methods, except for the tests.
Luke
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote: The only minor thing I can see would be that you will end up with a slight asymmetry question of if we use $:attribute for a private attribute, do we call :method for a private method? That occurs no matter if .method means $self.method or $_.method. Anyhow, I don't see why not. :)
RE: .method == $self.method or $_.method?
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 Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com
Re: .method == $self.method or $_.method?
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 http://convolution.nl/gajigu_juerd_n.html
Re: .method == $self.method or $_.method?
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 self calls of the form: o.frobme(...) Now that has some interesting possibilities for variants. We could have c.bless(...) which would presumably give you the class of the invocant. Perhaps more interestingly, if o and c are functions, then you can provide arguments, with a default of 0. So the above could really be short for o(0).frobme(...) c(0).bless(...) Now, we also have this other problem that we're forcing people to name all the invocants for MMD methods, poor things. But with the above notation, the first invocant is o(0), the second invocant is o(1), etc. Not that we would encourage people to code this way, but it'd be nice to have a way of getting at the actual args in the same way we used to always get at them using @_. (Such a notation might well be useful in wrappers that don't know what they're being wrapped around, such as various debugging wrappers.) That's what Sleepy Brain says. But Coffee Brain despises Sleepy Brain. :-) Larry
Re: .method == $self.method or $_.method?
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, actually!) How 'bout a single underscore? _.frobme()?!? Michele -- L'amava come si ama qualcosa che e' necessario alla vita. La odiava come si odia chi tradisce. - Laura Mancinelli, Gli occhi dell'imperatore
Re: .method == $self.method or $_.method?
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 c, if we decide to have that too. Coffee Brain perks up and points out that for strategic psychological reasons it really likes the fact that, Huffmanly speaking, the dynamic class can be as short as c and the static class as long as $?CLASS. Larry
Re: .method == $self.method or $_.method?
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 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 strike me as visually distinct enough. They just look like someone stepped on the front of your expression. Larry
Re: .method == $self.method or $_.method?
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. Suppose we pick o for that, short for object. Then we get self calls of the form: o.frobme(...) Now that has some interesting possibilities for variants. We could have c.bless(...) Wow. With those single-casting-cost cantrips, the OO color will surely make a huge comeback in Perl6: The Gathering golfing tournaments! :) I like them. They look really really good to my eyes after the first 20 minutes or so of mental reconfiguration. For some strange psychological reasons, they make Pugs 6.2 so much more enjoyable to work on for me. :-) Thanks, /Autrijus/ pgpuLiyu2UtLd.pgp Description: PGP signature
Re: .method == $self.method or $_.method?
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 strike me as visually
distinct enough. They just look like someone stepped on the front
of your expression.
But then do 'c' and 'o'? They're too identifier-like IMHO to be
psychologically associated with something 'special'. It kind of reminds me
of some fortran code I saw (I don't know fortran) and I could hardly cope
with those 'c'omments...
(However I would be favourable to {one,two} letter(s) long builtin
functions/operators, when they are frequently used (think huffmanization)
and talking about language design in general.
Michele
--
Your right, I didn't think of that at all, but still, who's gonna go into
the temp internet folder and create a cookie? At least not most users.
Of course *most* users aren't going to do that. *Most* users aren't
trying to hack your site! You don't program securely for *most* users -
you program securely for the few users who *are* trying to be malevolent.
- Paul Lalli in clpmisc, Re: free source authentication script
Re: .method == $self.method or $_.method?
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 {
for ($.prisoners) {
.put($lotion, $skin); # is the same as
$_.put($lotion, $skin);
}
}
It is not us, it is not self, it is not here, it is, err, just the
default. For implies it in this case.
Contrary:
this puts the lotion on the skin
self ~~
method cooperate ($self:) { # in class Prisoner
# this method puts lotion on skin, haha
$self.put($lotion, $skin);
}
We are discussing a certain thing, which is the invocant. It's not
default. The default might be something else altogether. It's pretty
obvious that in a method like this the invocant is the default, but
what if it isn't?
Perhaps i'm sort of forcing this distinction.
However, I wouldn't be too happy with having to do this, though:
method data {
map { $OUTER::_.process($_) } .things;
}
or having to name the invocant every time I want to map {}.
Lastly, what is wrong with
$.method?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpqRpkMb5Me5.pgp
Description: PGP signature
