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 { ... };

14 Comments

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.

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.

Leave a comment

About Yuki Kimoto

user-pic I'm Perl Programmer. I LOVE Perl. I want to contribute Perl community and Perl users.