As the debate over revising the OO tutorials in the Perl 5 core continues, one point has come up as salient:
I am disappointed that after all this time we have no consensus on how to say in Perl "Class X has attribute Y" when so many other languages have solutions that have freed their users' minds up to move on to higher-level problems.
— Peter Scott, Re: Revising Perl's OO docs - a new OO tutorial.
Fortunately, Jesse Vincent opened the door to a discussion of something other than what's appropriate in core documentation:
I'd love to see proposals (soon) for how we might do this in the core for 5.16 or 5.18. I'm not promising I'll accept one of them, but I'd love to see us actually discuss such a thing.
— Jesse Vincent, Re: Revising Perl's OO docs - a new OO tutorial
This is a great opportunity for armchair language designers to address a notable feature gap in core Perl 5. Here are a few constraints I think any design must address:
- New syntax is necessary, though it should be optional (as much as I dislike the idea of feature.pm, it hasn't yet been deprecated, so you might as well use it).
- New syntax should be as compatible both with Perl 6 and Moose as possible.
- New syntax can be simple (that is to say, there's no need for 5.16 or 5.18 to include a full type system such as Moose provides) but should allow for extension (it's okay not to support method signatures as long as it's possible to add them in the future).
- New syntax should allow enhancement with something like Method::Signatures.
- The new features should encourage programmers to do the right thing by default without forbidding them to do other things when necessary.
You can get by without creating a MOP, but the real power comes from doing something more than fields—if you can declare a class, declare attributes, and declare methods without having to bless references or write your own constructor, accessors, and mutators, so much the better.
Yes, a standard way to declare attributes in Perl would be a wonderful thing. I think I would go about it much differently, though: start from the MOP. Include a bare-bones MOP in core Perl, which allows for introspection of methods and attributes, and maybe a bit of symbol table manipulation (as you brought up in a previous article). Then on top of that, add a bit of syntax (a 'has' keyword, perhaps, what it is isn't really important), which does nothing except annotate the metaobject for the current package. From here, any of the object systems on CPAN can just introspect the MOP, and generate whatever accessors, or constructors, or whatever they want, without having to all export their own 'has' sugar function, or whatever other incompatible things they do now. Core doesn't really need any accessor or constructor generation to start out with - that can come later once this is already well established.
From this kind of basis, we could then also add things like a 'method' keyword, to differentiate functions from methods, and get rid of the annoying guesswork that things like namespace::autoclean have to do, and move forward in that direction. Or a 'class' keyword, and start adding things like inheritance introspection to the core MOP. But having a standard place to go to look up all of this information, cleanly and in pure perl, I think is the key to making this work well.
While I agree with adding MOP to the core, I certainly hope people see this as the digression that it is.
It would kill me to see Class::MOP touted as the answer to the current discussion on tutorials. It's bad enough that nobody seems to be willing to step back and discuss the purpose of tutorials, and instead get into arguments about whether THEY (p5p) use 'man' or 'perldoc' to view Perl reference material, and somehow project this onto Perl newcomers reading tutorials as if it's the same situation.
I think I will begin pulling my hair out, though, if somebody runs with this and "settles" the debate by saying "We have Class::MOP now, so take CPAN modules out of the tutorial in favor of MOP."
The longer I follow the list, the more I believe p5p needs to be taken out of the documentation loop (collectively, that is. There are individuals who would do fine in both roles.)
To be clear, when I was referring to a MOP in my comment, I was referring not to Class::MOP, but to a new core feature, which handles some basic things Class::MOP is currently used for, but with cleaner syntax and much better integration with the language itself.
As for the documentation issue, on some level it is a valid point that we have to refer to non-core things for something like basic object orientation. The reason for this though is that the object orientation features in core are actually terrible, and the solution is to actually fix them, not just continue either punting everything to CPAN or sticking our fingers in our ears and pretending that nobody needs anything more than 'bless'. I fully support Dave and his documentation goals, but there does also need to be effort on the other side: when issues like this come up, we need to be able to take that and look at how we can also make Perl the language better (and that I think is the point of this post).
I would certainly vote for a MOP. A MOP would allow CPAN extensions like Moose (that I use extensively) much easier to write. And probably a lot faster.
But my current favorite feature, the one above all others, is Method::Signature. The full argument signatures. Thats the one I would gladly do grunt work to make happen.
> when issues like this come up, we need to be able to take that and look at how we
> can also make Perl the language better (and that I think is the point of this post).
For the record, I definitely agree.
And I understand that this post was talking about the digressing issues in the thread, rather than the root of it.
I guess I was just voicing my frustration - though in the wrong venue. My bad.
Good that there is noise. It means that the community is alive.
For what we need in core, I think we should really concentrate on the stuff that is hurting Perl. When this stuff is fixed, Perl 6 can take as long as it take to be finished.
IMHO:
- No OO out of the box. Yes, I know bless. Perl is a great language with a lot of shortcuts and do-what-I-mean facilities. The boilerplate and the verbosity needed to write OO with bless feels not really Perl.
=> Moose. Would it be faster within core? Would this empower the Moose dev to tackle the starting time issue?
- Exception handling.
=> Try::Tiny looks the way to go.
- Threading
=> This seems like a more fundamental problem (lightweight threads) and I don't if CPAN modules offer a complete and *easy* to use solution.
C.