Hi again Ovid,

Well, you've made it clear in your replies in this thread that your intent is nothing less than to extend the Perl language itself to have a built-in object factory. Better than any of the other object framework/tools that currently exits for Perl -- and better than any that exist for any other language, built in or not.

Wow. That's an ambitious goal! Were it to become reality, that would be fantastic.

However, foremost in my mind, besides what Fletch highlighted, is what I mentioned earlier: that the last time someone had an idea this grandiose and it was stuffed into Perl, we got the decade-long smartmatch fiasco. Meanwhile Damian Conway and the rest realized that wasn't going to work, so they started the "Perl6" project, squatted on the Perl name for 15 years, blocking Perl's major release process, and finally, thankfully, took their ball and left to play elsewhere.

Many people said during that ordeal (I think you were among them?) that Perl did not deserve a major version release because it was lacking at least two prerequisistes: a built-in method signatures framework, and a built-in object framework.

IIUC from reading here, signatures are likely to be implemented in Perl 5.32 or 5.34. I'm not a fan of that personally, for the same reason I am not a fan of your idea: I will continue to use Method::Signatures because I don't think the new stuff is as good, so now my perl will have stuff built in that I don't want and won't use. Frankly, I don't think that is the Perl way.

I'd much rather see signatures and Cor, or whatever /p(?:7|34|42|2021)p/ decides upon, included in the next major version release of Perl.

Like it or not, Moo is the de facto standard for modern Perl application development. "Real developers" (coff, coff) of "large-scale codebases", who may or may not be "heavily, publicly involved in the language" know this, and maintain uncounted applications, all around the world, that depend on hundreds of CPAN modules, as well all their in-house libraries, that are all based on Moo. None of those "real developers" is going to change any of that production code; it's absurdly arrogant to think so.

Your own mostly wonderful Test::Most is a great example of how a designer's assumptions that are baked in make things less than completely Perlish. RJBS decided that he would export methods named all and any by default from Test::Deep, then you implemented Test::Most in a way that disallows controlling the bundled imported methods. So now it's impossible to test code that uses a method named any, e.g. from List::Util, without fiddling with the symbol table to rename the methods Rik and you assumed everyone wants exported.

I wish you well, but please adjust your plan to aim at the next Perl major version release. Perl can't withstand another backward-compatibility mistake that hamstrings it for a decade.