.
On 15 May 2005, at 16:17, Rob Kinyon wrote:
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF, we should use $self wherever $?SELF would be used. $_ is still the topic and would be the default invocant if you have .method($foo). What I'm saying is that you can have
method ( Int foo ) { $self.otherMethod( foo ); }
and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using JS as part of my argument.)
If you have method ( Int foo ) { .otherMethod( foo ); }
That would be method ( Int foo ) { $_.otherMethod( foo ); }
Just like expected.
My ill-considered and probably not very understandable thoughts:
- As has been said with great eloquence earlier, virtually everywhere in Perl 6 so far when you leave something out the default is taken to be $_
- As has also been said, elsewhere, internal consistency is a great feature of a language people are trying to learn
Given these two points, in my mind anything other than making
.method($foo);
mean
$_.method($foo);
is utterly absurd. If it means $_.method($foo) outside a method definition and $?SELF.method($foo) inside one then I think it's a reasonable expectation for people learning Perl 6 to throw up their hands and start complaining loudly (and possibly going back to their previous language of choice).
It also seems to make sense to me that the invocant of a method is the default topic for the method body - that is, after all, what that code has been invoked in order to do something to/with. Is it really a serious hardship to do what you have to do everywhere else in Perl 6 if you want to preserve the topic, and give it a name of your own choosing?
method m($self: $foo) {
$self.do_something();
}is hardly difficult to deal with in my opinion. Neither is
method m($foo) {
my $self := $_;
$self.do_something();
}for that matter. Remembering not to clobber the topic when you want to keep it will be second-nature to Perl 6 people very shortly after they start, I'm sure, as it's always seemed to me that it's going to use a lot more things which allow you to do a lot of topic manipulation instead of having to think up silly variable names all the time (given {} will be particularly handy for my code, thank you very much for that!) Thus I don't think that given {} and other such things inside the method body are going to be something people will particularly find problematic with regard to clobbering their invocant, as there is an easy and clear syntactic way to give it an alias, and normal variable binding can rescue it at any point up to the point where you assign something else to $_ (assuming I've understood binding correctly, of course). And indeed afterwards, if you use $?SELF. Which, to be honest, I'm not particularly keen on in terms of appearance or ease of typing, but I don't think we're going to need it except in 'emergencies' - $_ and the invocant naming syntax will provide plenty of opportunity for people to refer to $? SELF by a saner and more appropriate name for their given situation.
In the long run I can see making sure .method() defaults to $_ everywhere will save me a fair bit of typing - my methods (in C++ and in Perl 5) are usually made up either of coordinating calls to other methods of the same object, which will be nice and simple due to being able to omit the $_ or $?SELF or other name I might have given the invocant; or made up of a bunch of operations largely concerning other objects, in which case the whole thing goes out of the window because you're barely talking to the invocant at all. In that case, changing the topic at various points is probably going to be an advantage, depending on the code structure of course.
That may lead to the potential issue of calling the same thing by two different names ($_ and $?SELF or $self or $this or $me or whatever) in the same method, but that's more a question of style than anything else - the careful programmer will make sure it's understandable what's going on, while the careless programmer will make a mess no matter what the language lets them do.
So that's what I think anyway. Not that anybody should listen to me of course, but I really can't see the logic in some of the suggestions being thrown about here, so I thought it was prudent to try and head them off before my favourite unfinished language gets spoiled.
