Mop for Beginners
Here are some comments on the mop-redux regarding situations in which Perl OO (code) is thought to newcomers or to outsiders. Such situations could be explaining code to an non-Perl colleague at work for a holiday substitution or a Perl class in high school.
The new mop-redux project does great work. Here are my pluses:
The syntax is very clear and simple. It uses the terms found elsewhere: "class", "extends".
The "is rw/ro" is intuitive. The fact that you can get someone started with OO without explaining constructors and accessor methods is a *big* advantage, I think.
The use of safe objects (using inside-out techniques) is a huge step forwards. No more inadvertent or lazy fumbling with an object's properties. This comes together with useful introspection facilities. Integrate the mop into Data::Dumper and I will more than love it. Even for newbies and outsiders who tend to dump a lot to get an understanding of what they have made this should be at least as easy as blessed refs.
The use of twigils for data fields "$!x" is something you are going to explain, but as it makes for astonishingly clear and concise code, this is something we should buy imo.
The mop has fast (enough) start up. For short scripts and often runs, something newbies do a lot, fast start up is crucial.
All this together makes for *huge* improvements over the OO that is in core at the moment and is certainly something to love very, very much. Thank-you everybody involved for doing it.
Now to the questions and remarks.
I wonder if it was possible to override the automagical "new" by a hand-typed "new" which first calls the "auto-new" and then lets you do some more initialisation. "BUILD" I always find a bit hard to explain.
The mop as proposed now includes basic method signatures. I wonder if this is in scope for a mop-redux. To me it should either be as comprehensive and poweful as Method::Signatures or it should be left out. Also, if method signatures are only implemented for OO this leads to the strange situation that you will have to explain old-style argument shifting in non-OO and method signatures in OO (or using an additional module for non-OO).
I think it would already be a huge benefit for Perl to only have the object building part in the core, plus a facility to integrate well with other modules. Method signatures, type checking and whatnot could then be built upon the mop later on while the new standard Perl-OO stays sleek and simple.
This also in the light that speed matters and 2013 is not an early year for OO.
To me it has a certain importance to keep the "use" section of my classes short. If I can "use mop" and have everything, then perfect. If it is feasible to build a module "My::OO" which loads the mop and other features for me, also cool. Not so cool is "use mop; use Sig::Natures; use Type::Checking use What::Not". You get the idea.
(Loading modules to change the nature of a programming language is so not what many people expect and / or accept..)
A big plus, I think, would be arrays and hashes as data fields. Especially for newbies references tend to be a bit complicated.
"use mop;" should go away in the long term, shouldn't it?
I blog about Perl.
Yes, it is. Though
BUILDis a better bet if you just want to do some initialization. Overridingnewwould be more if you want to do something along the lines of Moose'sBUILDARGS.It's less powerful than Method::Signatures et al, but at some point it will hopefully provide hooks that could be used by future Method::Signatures-like modules to soup up mop's method signatures.
I believe Stevan Little has been co-ordinating his signature work with Peter Martini who has been working on function signatures for the
subkeyword.It's already feasible to build such a "My::OO" module using Syntax::Collector or Import::Into.
use 5.010automatically enabledsay,stateandgiven/when. Later,use 5.012automatically enabled strictures and some other features.use 5.016enables still more.I'd hope that at some point in the not too distant future, a
use VERSIONline might also enable the mop keywords.Toby pretty much said it all, but I wanted to add a few things.
First off, thanks for writing up the blog post and taking time to discuss this, I really appreciate it.
In regards to the Method::Signatures idea. I have no problem adding a little more features to the signatures, in fact we recently added support for naming the invocant (
method new ($class: %args)) which I believe Method::Signatures supports. But that said, I would not want to bring in all the type checking stuff that Method::Signature does, since that would mean also adding a type system to the core which is much too ambitious.Toby is also correct in that I have been coordinating with Pete Martini in hopes that his (very pluggable) sub signature support can be re-used by the mop (and therefore make that pluggable too).
And lastly, as far as "use mop" goes, yes, once this is completely integrated into the core, that should go away.