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?
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 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?
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?
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: .($_) (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$_($_) (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?
Luke Palmer skribis 2005-03-29 6:14 (-0700): > method iterate () { > for (@.objs) { > .process($_); # oops > } > } There is an alarming similarity with for (@hashes) { .($_) } 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?
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?
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?
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?
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
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
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?
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 . 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?
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?
[ 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?
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?
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?
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
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?
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, 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: : 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, 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?
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?
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?
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?
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?
On Thu, Mar 17, 2005 at 02:21:09AM -0700, Luke Palmer wrote: > 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. 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. Thanks, /Autrijus/ pgpgqlszdlpCR.pgp Description: PGP signature
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: : 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?
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?
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?
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?