On the new mop

Stevan,
I'd like to comment on the new mop proposal before the official RFC,
as outlined
at https://github.com/stevan/p5-mop
Because I already see some prototypes into the complete wrong direction.
See e.g. https://github.com/stevan/p5-mop/blob/master/prototype/v2/closures.pl

In general:
1st) As ex-lisper I'm all for a mop. Sure. I know MOP's, CLOS and
Kiczales and all other books inside out.
       In clisp we recently added such a thing also because we just had to.
2nd) As ex-lisper I'm in doubt if a MOP will slow down perl by large
factors, as it happened with lisp if done naively.
       The current mop proposal is even worse than the Xerox PCL.
       In the end lisp was therefore doomed to be reborn mop-less as java.
3rd) If implemented well, the foundations of a class system could make
method lookups faster,
      not slower as a MOP would suggest.
      See my method optimization proposals
http://blogs.perl.org/users/rurban/2011/06/how-perl-calls-subs-and-methods.html
      and both of my YAPC talks (US and the upcoming EU)
http://cpansearch.perl.org/src/RURBAN/types-0.05_02/doc/yapc2011/index.html
      My YAPC::EU talk will specialize more.

Moose is already slow enough. I'll try to make it faster. This
proposal goes into the opposite direction, it will slow down Moose
even more.

To the details:
1st) The method dispatcher is based on AUTOLOAD. That's really very
very unfortunate and impossible to optimize.
Even if you move it into a BEGIN block. A complete no-go.

2nd)
my $Point = class { ... }
Here you miss out the opportunity of compile-time known types, and so
miss the opportunity of compile-time optimizations.

It will be much slower than
package Point;
my Point $Point = Point->new { ... }

or even
my $Point = Point->new { ... }

With a new class keyword you should take the opportunity to define the
package at parse-time and type the instantiation.
-- 
Reini

• On the new mop by Reini Urban
• Re: On the new mop by Stevan Little
• Re: On the new mop by David Golden