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
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'; %.baz = 'val'; %:ber = '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'; %.baz = 'val'; %:ber = '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.baz = 'val'; #ok - lvalue $obj.ber = '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, 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 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
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
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
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
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 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
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 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
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 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
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, 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
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
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
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
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