This week in PSC (157) | 2024-08-23
Just Aristotle and Philippe this time (Graham chipped in on IRC):
- we discussed the apostrophe situation: we will watch 5.41.3 break CPAN, and then evaluate the actual fallout. We like the idea of guarding this with a feature (which might need to be split in two, for the string interpolation case)
- we had a long discussion about backwards compatibility and
use VERSION
. Should "did you use VERSION?" become the new "did you use strict and warnings?"
use strict; use warnings;
- but as time and versions march forward this will not encourage people to use new versions.use strict; use warnings
is very useful for maintenance programmers. Please don't hide that. We should still encourage explicitly stating this in the top of the file.use strict; use warnings;
but alsouse v5.xx;
without using any of the features required by v5.xx. Please note that this is redunant anduse v5.xx
can be removed without limiting the functioning of your program".info()
function like PHP has that dumps all the relavant info, in particular what features are available, what's experimental, and what's in deprecation.% perl -e 'say info()'
@Brett: Re: info() - I think such information belongs somewhere in perldoc, not a function. I definitely agree with the first two bullets, see also Syntax::Construct (especially the "Good Practice" part) to know more about my view on similar topics.
PHP has the
info()
function for a very different reason: it tells you ⓐ what options the language has been compiled with because ⓑ you cannot examine them directly without shell access to the host. So it covers a set of requirements that simply do not exist for us, because there is no way to compile a perl with only some of its features. Whether you have any given feature or not depends solely on which version of the perl interpreter you’re running, not how it was compiled. A function that provides this information would just duplicate the documentation at a point where that information isn’t terribly useful.