Partly because I've got no responses for this proposal on p5p.

Considering that (mainly due to the tuits required to actually do significant things is concentrated upon a handfule of people) perl5 progresses slowly -- from 5.8 to 5.10 took 5 years; from 5.10.0 to 5.10.1 is taking 14 months and counting -- you shouldn't expect 5.12 to happen any time soon. Just because your post didn't get a reaction in 4 days doesn't mean anything.

And remember, 5.12 will happen. Just not this week.

No no, the first proposal, I agree, the solution to the original problem was well-accepted, which actually motivated me to look deeper. The patches I've sent, I do NOT want them committed, they are not ripe yet.

I'm not complaining, really. I'm simply confused because I write extremely rarely to p5p, and I don't know what to expect from there. And honestly, I don't know if there are people like me who still want something new from perl5. If yes, I'll be glad knowing that what I'm planning to do is needed. Don't look for hidden messages in my mail, or you'll find them :)

Say, have you tried Perl 5.10?

You're right, there ARE people developing interesting things, and that's why I'm in doubt. OTOH I don't know what motivation was for the person who did the great job of adding the MRO stuff. I also missed discussions about it, so I don't know if it was a feature generally found useful, or just a lone cowboy effort.

I don't know if it was a feature generally found useful, or just a lone cowboy effort.

The reason (as best I know) was that DBIx::Class was using the Class::C3 module, which I wrote the first version of as a sorta-kinda-joke-maybe-not, but Matt Trout (author of DBIx::Class) decide was really useful for keeping his Multiple-Inheritance hierarchy sane. My version was quite slow and basically a naive poor quality port of a Python version until Brandon took it over and promptly re-wrote it faster and eventually in XS. From there (I assume, cause I wasn't heavily involved) he petitioned p5p wrote tests and patches and got them to accept core changes that would make it possible for Perl to support the C3 MRO natively.

So basically, no it wasn't lone-wolf-hey-this-is-neat-lets-add-it, it was backed by a serious need in a major module that had lots of community support behind it, and it was something that was not easily and cleanly accomplished outside of the core.

As for the patch you have described, I would say that it is better as a module then a core addition. The reason being is that I can very easily see it causing issues with existing code (DarkPAN as they call it). I know I am guilty of occasionally using an imported function as a method (mostly just abusing Scalar::Util::blessed so that $obj->blessed returns the class it is blessed into) and I am sure many others are too. As for adding methods to a random SV, this is a major language feature and while cool probably breaks the well established package<->class relationship.

-stvn

It was basically Brandon Black bitching about how trying to change MRO (method resolution order) in Perl 5 was a pain and could someone do something about it. I recall the reason being that it was a biggest cause of slowdowns in Moose. Nicholas Clark dared him to write a patch, which he did. The rest, as they say, is history.

So sort of both, really :)

• another intruder with the mooring in the heart of the Perl

So my question is about how new, possibly not-so-cool features in perl5 are needed, - has everyone gone off to perl6? Is trying to add new stuff in perl5 is flogging of a dead horse?

I'm slowly wandering off to Perl 6, but I feel like I'm about the only one, there's still a strong community of Perl 5, and lots of cool stuff gets developed both on CPAN and in core. Perl 5 is not a dead horse (only the ponie is dead...)

I think the OP was referring to those who develop Perl, since Perl6 isn't out yet.

To be sure. I'm just pointing out a project that is still looking at ongoing development in p5, although it's not their principal focus.

Their package manager is written in perl, though.