Re: WTF? - Re: method calls on $self
I'd have to agree.
I also think that .foo should always mean $_.foo in methods, without causing
any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of
legacy in the Perl6 language.
OK - As I understand it, this is what A12 says:
class Foo {
# normal instance variables
has $.x;
has $.y is rw;
has $:z;
has @.foo is rw;
has @:bar
has %.baz is rw;
has %:ber
method one { return 1 }
method :two { return 2 }
# some class variables
our $.class_var1;
our $:class_var2;
our $.class_var3 is rw;
my $.class_var1_visible_only_to_class;
my $:class_var2_visible_only_to_class;
# implicit object set in $?SELF
method grr {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = .one; # hmmm - here is the subject of all of our pain
my $b = .:two;
}
# explicit object
method roar ($obj:) {
$.x = 1;
$.y = 2;
$:z = 3;
push @.foo, 'item';
push @:bar, 'item';
%.bazkey = 'val';
%:berkey = 'val';
my $a = $obj.one;
my $b = $obj.:two;
}
}
# external use of object
sub squawk ($obj) {
$obj.x = 1; # fails - no accessors
$obj.y = 2; # ok - lvalue accessor was created for us because of is rw
$obj.:z = 3; # fails - no public accessors - even if is rw
push $obj.foo, 'item'; # ok - lvalue accessor created
push $obj.bar, 'item'; # fails - even if is rw
$obj.bazkey = 'val'; #ok - lvalue
$obj.berkey = 'val'; # fails - even if is rw
my $a = $obj.one;
my $b = $obj.two;
}
Somebody correct me if I had things wrong up above.
So in all of that example, all of the instance variables and methods are
easily accessed and almost all of the rules are clear cut. So under this
final proposal we now have the following:
class Foo {
has @.elems;
method rock {
.wizbang; # called on $?SELF - looks ambiguous (what is $_)
.foo for @.elems; # fails with an error - ambibuous compared to .wizbang
}
method stone ($obj) {
$obj.wizbang;
.foo for $obj.elems; # supposedly fails ($_ no longer =:= $?SELF) :(
}
}
sub conglomerate_solid ($obj) {
$obj.wizbang;
.foo for $obj.elems; # ok here
}
sub petra ($obj) {
temp $_ = $obj;
.wizbang;
.foo for .elems; # confusing - but ok (called on different objects)
}
I don't think the most recent proposal (er edict) is really all that friendly.
I've been hoping that it is a case of linguist/architect/benevolent president
turned psychologist and that it is a foot in the door approach of getting
both sides of the ./method argument to just give up and be quiet.
This latest proposal seems to add ambiguity all in favor of getting rid of a
slash. Looking at all of the instance variables and method accesses in the
method grr up above, a method call of my $a = ./one really isn't that out
of place. Once the object is explicit, then all method calls change
(including the private ones) while all of the instance variables stay the
same.
I think that .method == $_.method needs to always hold true. I still think it
would be nice - though not as important to have ./method (or whatever
variation you want) work inside methods. I don't think that $_ should ever
default to the invocant ($_ =:= $?SELF) (which should be easy enough with
method a ($_) { ... }).
method concrete {
./wizbang;
.foo for @.elems;
.foo for ./elems; # possibly odd looking - but not confusing
}
Please, lets pick something sane. Here I go speaking for the list, but I
don't think we will find many that think .method syntax breaks in methods if
$_ is rebound as a very sound concept.
Paul
Re: WTF? - Re: method calls on $self
On Thu, July 14, 2005 10:47 am, Autrijus Tang said: If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. I have been watching perl6-language from afar and not really contributing. But I have to say that in this case I do agree with Autrijus Graham.
Re: WTF? - Re: method calls on $self
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote: Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) Aankhen
Re: WTF? - Re: method calls on $self
Aankhen skribis 2005-07-14 12:39 (+0530): Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. // Carl
Re: WTF? - Re: method calls on $self
If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. Thanks, /Autrijus/ pgpyMrTt9ljfK.pgp Description: PGP signature
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote: On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. Yes, let .foo still mean $_.foo, unconditionally, please. The `./` is nice, but I'm willing to give up the syntax in favor of letting .foo always mean $_.foo. Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. So long as .foo (pretty please) means $_.foo all the time (with sugar on top?). -kolibrie
Re: WTF? - Re: method calls on $self
Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
It's a little klunky but does localize the override rather visibly.
Doubtless people will generally put the use dot at the front though.
Larry
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
If .method always means $_.method ($_ being the topic) then I don't see how
it is ever ambiguous. Unless I missed where nested loops would also
disallow .method because people might not be able to keep track of the
topic.
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
Why must anything special be done in the given block to allow .method if
it is always $_.method? Since I know $y is the topic in this block I know
to expect $y.abc to be called. There is no ambiguity. An error here
would just be confusing.
Now, for those who want .abc to call $?SELF.abc within the given block
then I think it would be clearer if they spelled out that intention with
something like
given $y { use dot '$?SELF'; # or just 'use dot' with suitable default
when 1 { .abc } # calls $?SELF.abc
}
--
Rick Delaney
[EMAIL PROTECTED]
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
ICK! TOO MANY CHOICES!
If we have pragmas for the 99 Perl6's that every wacko wants to
have, we won't have any readability.
The syntax needs to be consistent and useful, even at the price of
some danger.
I don't want to be using a language designed for idiots - I know
what I'm doing, and I like the power that perl 5 has given me.
How many times have you typed
map { chr }
map { lc }
grep { defined }
and then got bummed out that you can't have
grep { .is_moose }
since it's in a method.
That really sucks.
I'd rather have '.foo' not work on $?SELF at all than have that.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpaUXI5Wijpd.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-14 13:39 (-0700): On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. Thus it never means $?SELF.foo without $_ being the same thing, and thus it always means $_.foo, and thus there is no ambiguity about what .foo means, and .foo can mean $_.foo even if $_ isn't $?SELF, as $?SELF is never a factor in the decision what .foo means. Good, glad that's solved. We have normality. It's a little klunky but does localize the override rather visibly. Doubtless people will generally put the use dot at the front though. Doubtless if you really insist on this feature, Perl 6 will see its first fork very shortly after its release... But have no fear, because it will run all standard Perl 6 code too, as the thing that the fork introduces used to be an error. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
Yuval Kogman skribis 2005-07-15 1:09 (+0300): use dot; If we have pragmas for the 99 Perl6's that every wacko wants to have, we won't have any readability. The syntax needs to be consistent and useful, even at the price of some danger. Agreed. I don't want to be using a language designed for idiots - I know what I'm doing, and I like the power that perl 5 has given me. Me too. I'd rather have '.foo' not work on $?SELF at all than have that. .foo never working on $?SELF is consistent with the initial design, the idea that the default variable is always $_ (as explained very well by Damian), and the design until a few days ago. I really do not understand why Larry has changed his mind about .foo, as the meaning of .foo has not been topic of discussion for a long time now. The syntax of ./foo did receive a lot of both negative and positive attention, and I could understand that ./foo, being found ugly by some people, would be pulled out of the language in favour of some yet to invent syntax, or perhaps without replacement. That, however, has nothing to do with .foo. Or at least HAD nothing to do with .foo, until Larry decided that if $_ := $?SELF, .foo would be special all of a sudden. If that is so, then lc without arguments would also need to be special, as that also defaults to $_, which would then be the same thing as $?SELF, which makes things special. lc without arguments would also need to be forbidden, following this way of thinking. We can only hope our dictator turns benevolent again, at least regarding the one thing we all agree about (and have agreed about for quite some time): that .foo must always mean $_.foo. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote: On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote: On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. If you say use dot; I'd rather have '.foo' not work on $?SELF at all than have that. Um, that's what I was hoping for too. Let .foo mean $_.foo, and never $?SELF.foo, unless of course $_ happens to contain $?SELF at that moment. (sugar, anyone?) -kolibrie
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote: Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? The former. But this is strictly a joke in response to nothingmuch's two characters shorthand criteria on #perl6; please don't hold it against me, or invoke the famed joke-turned-into-reality p6l device! :) Thanks, /Autrijus/ pgpiqjSf1TXa2.pgp Description: PGP signature
Re: WTF? - Re: method calls on $self
On Tue, Jul 12, 2005 at 04:43:06PM +0530, Aankhen wrote: : I agree with what is being said here. `.method` is a great way to : eliminate a lot of repetitive, tedious typing. Surely there is a : viable alternative that doesn't involve outlawing it? Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Larry
WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
I feel a me too post is in order.
I've written code that is 2-3 levels of nested given/when in a
method of an object that wasn't the topic.
I did not feel confused at all, juggling .foo and ./foo, which are
visually distinct, and different to type. They convey a big
difference of meaning, even if it's only 1 char apart.
I think a solution to the problem of being able to use those two
well, is not a solution, because there isn't a problem.
On Tue, Jul 12, 2005 at 12:59:22 +0200, Juerd wrote:
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.
This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.
That's the default, and I'm not changing my mind ever again, at least
till next week.
I can wait till next week.
use self this;
use self self;
use self o;
use self ./;
use self ;
Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.
Obviously, use self is the least attractive of these, but I would
still prefer it to outlawing .foo.
If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.
Yes, this is possibly a hazard for cut-n-pasters. But then,
you weren't supposed to be cutting-n-pasting anymore, were you?
No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.
In Perl 5, I really hate
for ($object) {
$_-method(...);
$_-method(...);
$_-method(...);
}
And the Perl 6 equivalent until your revelation,
given $object {
.method(...);
.method(...);
.method(...);
}
was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah!
pgpL6XkyQ00ZQ.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
On 7/12/05, Juerd [EMAIL PROTECTED] wrote: [snip] Disallowing .method here means a huge step back in time. Back to $_.method or $object.method. [snip] I agree with what is being said here. `.method` is a great way to eliminate a lot of repetitive, tedious typing. Surely there is a viable alternative that doesn't involve outlawing it? Aankhen
