mop minus proposal
I'm creating mop-minus-proposal project on GitHub. Current experimental mop implementation need big core change. so I think writable object orientation support is needed without core change or with minimal core change.
The following is example. This is not only specification. This code work on Perl 5.20.1+. Important thing is that the following code don't use Perl source filter, such as Filter::Simple.
# Point.pm
package Point {
use mop::minus;
has x = 0;
has y = 0;
# will be "method clear { ... }"
sub clear ($self) {
$self->x(0);
$self->y(0);
}
}
1;
# Point3D.pm
package Point3D {
use mop::minus;
extends Point;
with Role1, Role2;
has z = 0;
# will be "method clear { ... }"
sub clear ($self) {
$self->z(0);
}
}
1;
# Role1.pm
package Role1 {
use mop::minus;
# will be "method foo { ... }"
sub foo {
return 'foo';
}
}
1;
# Role2.pm
package Role1 {
use mop::minus;
# will be "method bar { ... }"
sub bar {
return 'bar';
}
}
1;
# main.pl
use Point3D;
my $point = Point3D->new;
print $point->x(0);
my $x = $point->x;
Description: The following code is implemented by keyword API added in Perl 5.12. Old perl can't parse "KEYWORD FOO", but by keyword API feature, Current perl can parse it.
has x = 0; extends Point; with Role1, Role1;
The next is package block syntax. This is added in Perl 5.14. You can write package NAME { ... }.
# Point.pm
package Point {
...
}
The next is subroutine signatures. This is added in Perl 5.20. This is yet experimental. You can write sub ($foo) { ... }. I'm glad method signatures is added in future Perl.
# will be "method clear { ... }"
sub clear ($self) {
$self->z(0);
}
I'm Perl Programmer. I LOVE Perl. I want to contribute Perl community and Perl users.
Thanks for the demo. It shows that introduction of readable OOP in Perl is less a technical problem but a problem of agreement. We could already have this if it was put into core, enabled by default (!) and not marked as experimental (!!). Only when it's enough to put a single
use v5.2X;at the top of your code to, I will start telling people that Perl natively supports OOP (since version 5.2X).mop::minus looks like more like Moo/Mouse/Mo than MOP.
MOP means « Meta Object Protocol ». I see nothing like that in mop::minus. mop::minus seems to be just some cool syntax for Object::Tiny. This is just deceptively simple.
Besides what Olivier mentioned above I wonder about the use of Parse::Keyword. The author of that module states in the POD for that module that it is deprecated and should not be used.
The more of yet another
/^(mop|Mo)/module or yet another comment like this I read, the more I think about switching my favorite programming language. A clean, default syntax for defining classes and methods in Perl (as usual in other programming languages with support of OOP) is almost as vaporware as Perl 6. Sure one can discuss about details and differences between all this Moooos and mops, but without decision on any standard way to do OOP in Perl, the language is going nowhere. I am tired of thinking about which way modern Perl may or may not go, so my next project will definitely not be in Perl anymore.Parse::Keyword has issues, but it is possible to work around them. (And I don't think Yuki Kimoto's code triggers the problems in Parse::Keyword anyway.)
There are a lot of class/role frameworks, but the decision making process for which to use is actually very simple:
Start with Moo, and if you outgrow it, use Moose.
You can mostly forget about the others.
Also there's Moops which is not a class/role framework itself but syntactic sugar for either Moo or Moose.
>jakoblog.de
thanks.
I think Perl already have most of tools to write writable OO syntax. so I write demo to inform people.
Olivier Mengué (dolmen)
>MOP means « Meta Object Protocol
I have known this. but people likely to think mop is the name of Perl OO support in core.
mop::minus don't contain meta object protocol now. but mop::minus syntax can contain meta object protocol if user need.
hubris
Parse::Keyword is wrapper of pluggable keyword in C level.
mop::minus is demo. I don't release CPAN. The reason I use Parse::Keyword is that it is easy to create demo.
jakoblog.de
>The more of yet another /^(mop|Mo)/ module or yet another comment like this I read, the more I think about switching my favorite programming language.
Yes, you said. Perl don't have clean syntax of OO in core. and many many Module to support OO is released to CPAN.
I don't think this is good. so I hope Perl core support writable OO syntax.
Toby Inkster
I think Parse::Keyword have problem. This don't support run-time support, and don't support closure in subroutine.
I think mop::minus avoid this unsupported features in Parse::Keyword.
Toby Inkster
>Start with Moo, and if you outgrow it, use Moose.
mop::minus is proposal to Perl core, not CPAN module. I don't want to release OO support module to CPAN any more.
I hope Perl core support writable OO syntax.
Yuki,
You might be interested to know that I am now working on YAMP (Yet Another Mop Prototype) (I really should do something to link all the prototypes, perhaps merge up all the separate git repos into a single repo with branches for each prototype, hmm, anyway, that is for later). At the moment it is in the VERY VERY VERY VERY VERY VERY early stages, so please be careful to not infer too much about what the final version might look like or how it might behave.
As for mop::minus, I totally agree with you, the previous (no longer current) prototype (and the one before that) was too complicated and requires to many things to be added to the Perl core. In this latest prototype I am looking to add the absolute minimum amount of code, behavior and syntax possible to the Perl core while still providing a powerful MOP when needed. I am also trying keep my objectivity as much as possible. My own opinions tend toward the be "strict, verbose & theoretically correct" side, but a core MOP should not enforce that opinion (perhaps the optional syntax layer will, but that is still to be determined).
Yours, Stevan
Stevan
>You might be interested to know that I am now working on YAMP (Yet Another Mop Prototype)
I'm glad to know this project. I also try to add some meta object protocol features to mop::minus.
While I appreciate the effort, I cannot understand why another OOP support when there already a lot, and with a very good implementation (Moose being probably the most adopted).