The proposal of separating method keyword from mop
method keyword is the syntax to write method simply.
method clear {
# You can omit "my $self = shift" by method keyword
$self->x;
}
And method keyword give Perl ability to know it is subroutine or method.
I think that method keyword isn't part of Meta Object Protocol even if mop use it as the part of module features. method keyword is independent feature.
If so, we can implement method keyword before mop release. Big jump is hard, small jump is good. If method keyword can work independent feature, I think it is good that method keyword is implemented into Perl core before mop release.
And user which don't use mop can get the benefit of method keyword. And anonymouse method can be implemented.
my $method = method { ... };
I'm Perl Programmer. I LOVE Perl. I want to contribute Perl community and Perl users.
Perl does already offer an official way of marking a sub as being a method:
sub foo : method { ...; }It does not automatically shift off
$self. Other than as a hint of the sub's purpose for people reading the source code, it does very little. (It vaguely influences the parsing of indirect object syntax.)Yuki - I will discuss this with the other MOP developers, I am not entirely opposed to it. Please add an issue to the github repository for the mop so that we can discuss it in the proper forum.
Yuki - Actually, I retract my earlier statement, I don't think this is a good idea.
Just adding the keyword "method" that automatically shifts off the invocant and names it $self is not altogether that useful. For instance, this does not help for class methods in which calling the invocant $self is not really appropriate. In order to solve that you would need to also include signatures and a means of defining the invocant in the signature (which we recently added to the mop, again borrowing the Perl 6 syntax).
So while on the surface, this might seem convenient for a large percentage of usage, it is ultimately an incomplete solution that leaves some difficult holes in the language design.
I would however agree with, "Big jump is hard, small jump is good..." I do wish there was a way this wasn't going to be a multi year project, given all the prior art, but I guess there's nothing for it :(
> Big jump is hard, small jump is good
But I think better to have full specification for what should be implemented ("big jump"), and implement "small jump" only after that
There are already modules on CPAN which do this, [Function::Parameters](https://metacpan.org/module/Function::Parameters) and [Method::Signatures](https://metacpan.org/module/Method::Signatures) are the first that come to mind. More will be coming when new parser hooks are added (see any of Peter Martini's work on the subject).
I've also recently been working on Kavorka which I hope will one day be able to replace Function::Parameters as part of Moops.
@tobyink: have you considered joining the Function::Parameters project instead of forking a new implementation? It would be great to be able to build on what we already have, rather than forcing the user to have to choose between two (or more) competing solutions.
>Just adding the keyword "method" that automatically shifts off the invocant and names it $self is not altogether that useful. For instance, this does not help for class methods in which calling the invocant $self is not really appropriate.
In class method, Class name is assigned to $self. This is not bad. Now, people tend to think $self mean only object, but $self can also mean class name.
>So while on the surface, this might seem convenient for a large percentage of usage, it is ultimately an incomplete solution that leaves some difficult holes in the language design.
I think it is important that "this might seem convenient for a large percentage of usage". If Class method is called from $self, Dose Bad effect occur?
Most people don't use the syntax.
sub foo : method {
...;
}
This only increase typing count and don't have any meanings practically.
The point from normal user is that:
"Why we must write 'my $self = shift;' at the start of all of methods. It is boring work and I want to omit 'my $self = shift'"
The point from developer is that:
"Why we can't distinguish function call and method call. If we can't distinguish them, we can't write corresponding logic"
>But I think better to have full specification for what should be implemented ("big jump"), and implement "small jump" only after that
Perl core is already very complex. I think mop is large system. so if the parts can be separated and independent, it is good to add it to core little by little. If we afraid specification incompatibility, we can mark the parts as EXPERIMENTAL after mop release.
>There are already modules on CPAN which do this, [Function::Parameters](https://metacpan.org/module/Function::Parameters) and [Method::Signatures](https://metacpan.org/module/Method::Signatures) are the first that come to mind. More will be coming when new parser hooks are added (see any of Peter Martini's work on the subject).
I already know these modules, but these modules are CPAN module and only have source filter level implementation.
Important point is that we can use the features in core level.
Neither Method::Signatures nor Function::Parameters uses source filters. Method::Signatures uses Devel::Declare, which is an order of magnitude more reliable than source filters. Function::Parameters uses the Perl keyword API which is even more reliable. (And happens to be the same API the mop's syntax is implemented with!)
Ether, I have contributed some ideas to Function::Parameters, but my XS fu is not powerful.
Kavorka provides roughly a superset of FP's functionality (using a superset of its syntax). I've stolen a bunch of ideas from MAUKE. Hopefully I can point him at Kavorka some time soon and he'll steal a bunch of ideas from it too. If Kavorka never gains any users but makes FP better, then I'll count that as a success.