Can you be specific, what exactly is "concerning" to you about this proposal? What may leave people "shocked" about that wiki entry you quote?

"And don't get me started about some who I've heard of being shadowbanned on p5p - receiving emails yet their emails getting delivered directly to /dev/null."

How does this relate to the topic being discussed?

I am goncerned about the nature of implementation prototypes and that it was buried so deeply in the read that the guy who is responsible for Moose (end their elk) is greating the implementation, sure to turn into MooseNG. I don't expect any one to recall what I've said about it, so I'll state my tiny opinion again about what a unified OOP syntax/system looks like in Perl: if the resulting approach doesn't look and feel perlish then it's not going to be used or well adopted. I don't know what that looks like, the closest I've seen to date is Util::H2O. This may not be the way to go, but it is in the right direction.

To expand on the perlish nature of that I mean:

• if it results in gobs of pre-declarations like Moose, it will fail (again). Why? I don't think I need to answer that one.
• if it looks identical to insert your realy OOP language here, it will fail. Why? Because people who use it will go to another language when they realize support is superficial compared to other languages at best. It's also the opposite of optimize for fun. It's more like optimize so it doesn't look like Perl
• if it necessarily restricts the user to a subset of "standard" Perl, it will fail. Why? Because it violates the principle that Perl is defined by perl, and so far (and likely forever), will resist a traditional standard BNF; Perl may even have more to do with its Recursively enumerable characterisitcs than anything. This is why perl is necessarily part of Perl's standard definition. More proof of this is Perl 6's ash heap of attempts to do what perl does: at least 2 VMs, at least 3 intermediate/bootstrap languages, forray into fundamental support of grammers. There are more, but I'd have to think about it a little more.

So my challenge is to those who actually deal with implementation is to create something that extends Perl using the full breadth and POWER^POWERPOWER that perl as a *framework* offers. And recongizing perl as a Recursive enumeration framework and not the thing to be extended, it is Perl that needs to be minimally extended and decorated. IOW, it's not about creating a grammar using Marpa or go down the same failed path a Perl 6 - a failure so HUGE that it resulted in a completely new language that completely and utterly missed the target, yet simultaneously produced as VERY interesting thing so influenced by the need to define perl that itself had to become a formal Recursive enumeration framework. But perl is not a formal one of those, that's just one of its qualities. A tricky beast, indeed. I don't know perl internals, but I know that it is a beautiful and powerful mess that can most certainly handle whatever is needed to scratch this OOP itch with no or a few very boring modification.

Of course, all of the above could be complete garbage. There is a lot I admittedly don't know. My hope is merely to get people to think critically so that we can get a win. Everyone deserves it, especially the people who maintain this glorious mess for us.

Meh. Ovid's preachin' 'cause he's reachin'. I would be *very* surprised if he is not overstating the buy-in he has from ... anybody.

I do agree that it would be good for P5P and Sawyer to provide updates on their thinking and plans for the unwashed masses. That way there'd be less guesswork and innuendo.

(And FWIW I am opposed to bloating the Perl core with *any* OOP framework, even if there existed one as good as Ovid's dream. One size does not fit all in Perl programming.)