Front page | perl.perl5.porters |
Postings from November 2021
In a recent PSC call (whose notes I still have to write up - sorry about
that), a thought was expressed that we should do more "dogfooding" -
namely, using our own features in our own code. I'd like to encourage
more people to help us achieve this.
((Wikipedia has more on the origin of the phrase
https://en.wikipedia.org/wiki/Eating_your_own_dog_food ))
I personally find it very useful to be a bleeding-edge user of a lot of
my own new features; many of my personal-use CPAN modules and programs
are dependent on Object::Pad, async/await, and various of my
Syntax::Keyword::* modules. It's useful to be both implementer and user
of these new features, so as to get a good feel for what and how it
should be designed, used, extended.
We should do the same in core perl; currently we do not.
For example, I notice that basically nowhere in any of our shipped .pm
files are we using any of the following features that are already
present in perl releases:
* Postfix deref
* Sub signatures
* The `isa` operator
* try/catch blocks
nor any of the 5.35.x-added things like
* `defer` blocks
* Stable booleans
I'm also thinking about what'll happen when I merge the new `builtin`
functions related to the new stable-boolean ability.
I would like us to fix this shortcoming. One of the unfortunate outcomes
of the first (dare I mention it) "Perl 7" attempt, was our realisation
that so much of perl core's own shipped .pm files aren't even strict-
or warning-safe. That's looking better now, but we still have almost no
coverage of any of these other more-modern features. Shortly after the
release of try/catch in 5.34.0, a large bug was found in it that I fixed
in time for 5.34.1. I feel that if try/catch had been used a lot more
in core already by that point, it would have been found and fixed
within the 5.33 development cycle and not made it out that far.
Now, not every shipped .pm file is suitable for this - there are files
that are dual-life and have their own existence on CPAN. Also files
related to the build process (e.g. under regen/) have to execute with
an installed perl, which may be of an older version than the target
perl being built. But still, the majority of our .pm files ought to be
using a significantly newer standard of perl than they currently are.
I would like to encourage folks to assist on this. Again this is one of
those tasks that doesn't need any in-depth C or XS knowledge; any Perl
author ought to be able to take a core .pm file or two, and update it
with their favourite "new feature" - perhaps one from the list above. I
would be happy to assist and walk people through how to test and submit
these as PRs against core perl, and help review and merge the changes
that come out.
Who wants to help us out with this?
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Next