develooper Front page | perl.perl5.porters | Postings from November 2021

Re: Dogfooding our own new features - you can help

Thread Previous | Thread Next
James Raspass
November 24, 2021 13:53
Re: Dogfooding our own new features - you can help
Message ID:
What an excellent idea Paul! As only a very novice XS dev this sounds
right up my street. So am I right in thinking that anything in lib/ is
fair game? And dist/ is for dual-life dists that are upstream
somewhere else and need to maintain compatibility with old(er) Perl

On Wed, 24 Nov 2021 at 13:31, Paul "LeoNerd" Evans
<> wrote:
> 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
> ))
> 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
>      |
>  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About