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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.