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

Re: Dogfooding our own new features - you can help

Thread Previous | Thread Next
From:
James Raspass
Date:
November 24, 2021 13:53
Subject:
Re: Dogfooding our own new features - you can help
Message ID:
CAP4Ky=_QHcjN=40e3hHK0tgO4XiHKnEB7dW2MS0R5VmAi1A7KA@mail.gmail.com
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
releases?

On Wed, 24 Nov 2021 at 13:31, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> 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
>       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 Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About