Please not yet-another-oo-system, let's support frameworks
I'm very keen to be actively deprecating and removing syntactic oddities that folks should already be prohibiting via good perlcritic policies (i.e linting) hopefully in their editors and CI pipelines.
And standard perl is a good way for code bases to prepare for the future and derive real benefits right now. Both build on the meritocracy approach of CPAN.
It is that meritocracy that brought us the object frameworks Moose (which people seemed to feel was too big) and then Moo+Type::Tiny (which people seem to feel is about right). There are many other frameworks (object systems) which perl's minimalist internal object functions enable people to write, if one of them strikes a better balance of trade off's then there is nothing to stop it supplanting Moo as number one.
If you're going to write something in PHP you are also nowadays going to use a framework. Laravel comes highly recommended and sports an inviting website. There's also Symfony, Codeigniter, Zend is still around, FuelPHP and many others. People code in these frameworks not in naked PHP.
Ruby on Rails is similar story. People came to Ruby because they wanted all the benefits of RoR (and seem to be leaving because it's now seen as too heavy).
Returning to Perl, in the 90's people came to Perl largely via CGI.pm... a framework that made cgi-bin more bearable. It was the RoR of the 90's.
In Perl today I see people most excited about Mojolicious. It's batteries-included approach seems to have sidelined Catalyst and Dancer. It's sufficiently modular that non-web applications are building on it (Hello Mojo::TFTPd) and it's paving the way for async/await which is very vogue right now.
If you're coming to Perl for the first time you are probably coming to Perl via Mojolicious and likely aren't doing naked OO you are doing Moo.
If you're coming to C you're probably coming via GTK or similar. i.e. a Framework.
The game in 2020 is Frameworks.
Let's not fool ourselves in to thinking that yet another object system "but this time it's in the core" will have much impact. Which is not at all a criticism of the syntactic merits, rather i make a critique based on strategy. Let's show up for the right game at least.
My observation is that jQuery and Moo where/are successful because they enabled the entire community. It didn't matter if your company forced an ancient browser on you, or if your LTS distribution has an ancient system perl. ECMAscript evolved as a result of jQuery which was updated to take advantage of them if they where available.
Let's do that.
Let's put new stuff in Perl 7+ with an impact that is multiplied via the frameworks that we already use now so they can be better.
Additionally, let's also move stuff we love in to Core perl or perl itself. Stuff that's been in everyone's toolbox for years. Here's some ideas in no particular order.
- Syntax::Keyword::Try - hopefully you're already using this over Try::Tiny. Let's move it all the way in as part of Perl itself.
- Syntax::Keyword::Gather - another no brainer to go all the way in to perl
- Hash::MultiValue - probably not as is, but let's explore it. Plack uses this, so everything uses it
- Future::AsyncAwait - it's not ready yet, and it is very "me too" but its a nice paradigm even if personally i think "async sub" could be contracted in to one tbd keyword
- Something like namespace::(auto)clean but built in.
- The type keyword from cperl. It's tiny, its fast, it very natural
- Carp::XS or as builtin?
- Should Net::Time, Net::FTP, Net::NNTP, Net::POP3 and Net::SMTP really be in Core perl?
Related reading "Old Code Gets Younger Every Year"