Method Signatures or similar must be included for consideration in any future evolution of Perl 5: https://metacpan.org/module/Method::Signatures
]]>@Ron, if you’ll notice, hardly anything I suggest in a Perl 7 is really breaking, its more like changing the defaults. In this case getting current code to run might involve such simple things as no strict; no warnings; no utf8; use indirect;
etc. These are things that many people fault us for now, and also things that many people already do by default, or else get some package to do for them, i.e. Modern::Perl or else have a package import for them, i.e. Moose or Mojo::Base.
These are incremental changes that could be easily made if only we felt like breaking Perl 4(!) compatiblility, and change to some more modern defaults. Other than a real MOP and better concurrency what other better ways of doing X/Y should we add? The newest Perls have some of the best support for unicode in the programming world, just turning THAT on by default would benefit Perl and bring some wanted attention!
]]>What I meant was that the mop and the signatures should be included in some future release of Perl 7, not specifically in 7.0. All the things that breaks backwards compatibility needs to be in the first release though.
As to what numbering scheme to use: My problem with yearly numbers is not that it can be look like we’re breaking backwards compatibility, it’s that it will not be possible to tell when we do.
The only scheme that I can think of that will change that is to combine the suggested schemes as follows:
Rename the language from Perl to Perl5
Set a new major version E.g. v20 and keep it until we break backwards compatibility again
Use the release year as minor version
Keep the patch version scheme as today.
I.e the releases would be called:
Perl5 v20.2014.0 First release according to this scheme
Perl5 v20.2014.1 first patch
Perl5 v20.2015.1 next minor release
Perl5 v22.2017.0 next major release?
I don’t know how well this would play out marketing wise though, but I think we could get away with it without stepping very hard on Larry’s toes.
]]>The version number matters because it’s a mental barrier for breaking backwards compatibility and cleaning up the core. As long as we’re on major version 5 there will be a strong opposition against breaking backwards compatibility so we need to find a way to step the major version to get rid of the mental block.
]]>In my vision they now install Perl 7. Type use CGI
and it dies. They google for CGI and see the announcement that Perl 7 has been released and it drops CGI, because its not the recommended new technology.
You could still install it from CPAN, and it would still run (given some minor changes pursuant to the other things on my list. But at least it gives them reason to stop and consider if there is a better newer option.
To Olof@here.and.now: A version number like ‘Perl5 v20.2014.0’ is a bureaucrat’s dream. Many Perlers (not me, tho) love abbreviation. So, no thanx.
To Joel@here.and.now: I omitted a couple of huge points in my last post. Sorry: (1) Perl 5., etc would maintain back-compat. Perl 6. is a different language (i.e. should(?) break back-compat). And Perl 7.* should definitely break back-compat. That would be the point of its existence.
(2) Where is the (wo)man-power? If it was available, why hasn’t it been employed on Perls 5 or 6?
There is simply not enuf human effort to support these 3 streams of Perl. So I expect things to continue as before.
Despite the massive effort that has gone into Perl 5, I’d like to see future effort go into Perls 6 and 7.
]]>I think this gets at the actual social problem behind all these renaming schemes, which is that none of us want to thumb our noses at the work on the Perl 6 project: we want to get out from under it’s shadow without offending the people working on it. The trouble with calling version 20 “Perl 7” is to claim that it supersedes Perl 6. It’s not easy to describe a fork with a linear sequence of numbers.
I like “Perl 2013” as a compromise of sorts: the claim is that it’s this year’s Perl, it says nothing about whether Perl 6 may be next year’s perl.
“Secondly, what it does seem to signify is that the Perl community is going to abandon the stability … ”
I don’t get this. It doesn’t say it to me, and I don’t see why it would say it to anyone else. (Wouldn’t calling it “Perl 7” imply an even more radical break?).
]]>no indirect
I’d add no bareword::filehandles
and no multidimensional
.
Wait, isn’t that what use strictures
does, which is used by Moo? hmmmm… :)
no indirect
I’d add no bareword::filehandles
and no multidimensional
.
Wait, isn’t that what use strictures
does, which is used by Moo? hmmmm… :)
(I’m thinking mostly of uninitialized, void and once, but also to an extent numeric.)
]]>Another change one could make in such a release is to do all the things tchrist lists as needed for full unicode and utf8 compliance: http://stackoverflow.com/a/6163129/40468
]]>