Why do you want new major features in core?
I've heard some people complain about 5.12 and 5.14 not adding many new major features. Compared to 5.10 that's certainly true, but is that a bad thing?
Let's be honest, many (most) prominent new features of 5.10 are failures:
- Smartmatching? I think everyone agrees it is broken.
given/whenis even worse as it's almost impossible to predict if it will use smartmatching or not.- Lexical
$_? Mostly a new source of bugs, and the_prototype is merely a hack to work around lexical$_issues. - MAD? It never reached any usable form.
- etcetera…
A lot of others are not flawed, but are so uncommon that I haven't seen them being used in any code. UNITCHECK, stacked filetests, no VERSION, the list goes on…
In the end, there are only two new features of 5.10 that I end up using all the time: say and defined-or. These two features have one thing in common: they are small and simple features that make daily programming easier. Likewise my favorite new feature in 5.14 is the /r modifier on s/// and tr///. I don't know how we managed to do without that, it makes so much code so much simpler. I want more of those features.
On the other hand, there's another group of new features that is just as important, but not nearly as visible. It's the under-the-hood or right on top of it. Few people know how the $^H and %^H changed in 5.10, but if you're writing pragmas you'll appreciate them. These are expert features that few people will use, but those few use them to write the modules on CPAN that everyone else uses. These features are just as important, if not more so: they lay the foundation for progress by enabling (competitive) evolution on CPAN.
It is important for this progress to happen not in core but on CPAN. Because if modules screw up they can be discarded and we can try to come up with something better (which you can't with the core). Because modules easily allow an allow an ecosystem of TIMTOWTDI. But most of all because the Perl community is awesome at creating modules.
Few people outside the echo chamber follow know Steven's work on a perl MOP, but that may become the most important development in Perl OO since the arrival of his Moose (also written by him). Likewise few people are using Zefram's awesome keywords API, but that is what will allow us to do Devel::Declare kind of stuff in a sane way, and may one day open up doors to macros. Few people know of the Unicode improvements by Karl Williamson and others that make Perl hands down the best language for Unicode processing.
We can't always know end-user's requirement in advance. That's why big core features should be open ended. Maybe that doesn't make for spectacular perldeltas, but it does lead to a better end result.
"Likewise few people are using Zefram's awesome keywords API"
Link?
Probably tangential to the main point of your post, but I find UNITCHECK very useful for code that should inject methods only if the calling .pm isn't planning on defining them.
package Some::Module; use Module::That::May::Create::Methods; sub implemented { ... } # sub not_implemented { ... } will be created by the module we import 1;The imported module can inject a sub to run via Check::UnitCheck's unitcheckify function, so that when it runs any additional methods can be added as required, without needing to put sub implemented; stubs before the import.
Granted there are probably other ways to achieve this, but I'm grateful the feature exists.
@tempire - I believe the bulk of the public work on this is being done in Devel::CallParser and Devel::CallChecker. It is (as far as I know) entirely on the C level at this point.
It could. Imagine this future:
In this picture, the group of people who contribute to the standard download can be much bigger than p5p: individual CPAN authors.
In this future, the core could coordinate with this larger group to whip up modules that make some sort of key use of a new internal interface which exposes some benefit from that interface to “end users”, so releases with new internal interfaces could deliver include the surface features that go with them. The core perldelta may not look spectacular, but the overall distribution’s delta could be greater than ever.
I think that the most important rule here should be that when something is being added - then there should always be a plan how to remove it and when.
Independently I have the feeling that both smartmatch and given/when won by their cutesy not because they addressed some real pain point.
There's one feature I would like in core because as far as I can tell it's almost impossible to develop it on CPAN - which is customisable sv2pvflags().
Without this, I am forced to implement my "no stringification" pragma by basically wrapping almost every single operator that might stringify a reference, check its operands, and then presuming no (unsafe) references, call down to the original operator. This doesn't play well with any other op-hooking module, is slow to run, and -very- slow for me to write the code.
Were this hookable, it would be a trivially small module to write, much more compatible, both forward to future versions and back to previous ones, not to mention having effectively zero runtime cost.
I wonder if it would be worthwhile to make smartmatching disableable by pragma. also maybe it shouldn't have been use feature 'switch' but use feature 'smartmatching'.