develooper Front page | perl.perl5.porters | Postings from July 2011

On the new mop

Thread Next
Reini Urban
July 26, 2011 05:23
On the new mop
Message ID:
I'd like to comment on the new mop proposal before the official RFC,
as outlined
Because I already see some prototypes into the complete wrong direction.
See e.g.

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
      and both of my YAPC talks (US and the upcoming EU)
      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.

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.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About