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

Re: Creating an RFC process for Perl

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 11, 2021 08:59
Subject:
Re: Creating an RFC process for Perl
Message ID:
20210611085917.GC16703@etla.org
On Thu, Jun 10, 2021 at 04:50:00PM +0100, Paul "LeoNerd" Evans wrote:
> A quick thought while it's in my mind (and I hope to expand on this
> later - someone please prod me if I don't in the next few days)
> 
> There needs to be an optional section in the template for "scope for
> later expansion". E.g. if I had written try/catch as an RFC I'd
> definitely have explained "Future expansion: typed catch". It's useful
> to be able to say "I'm definitely not addressing this problem *now*,
> but I am leaving this hole for a future time".

You're right - thanks for thinking about the proposed process in the context
of "how would I write an RFC for X". It was also clear that we needed this
sort of section from the `foreach` discussions. I don't happen to have a
parallel universe to test this theory out in, but I think that it was the
right "plan" to introduce both the proposed RFC process *and* a proposed
RFC at the same time, instead of the alternative of just doing "here's a
proposed process" first.

Anyway, I am astounded to discover that in all the detail covered in PEP1
there isn't anything about this (so nothing to steal). I know that the
Open Group online man pages have a "Future Directions" section, so I was
wondering about that name, but it turns out that PHP have it in their
template as "Future Scope" -- https://wiki.php.net/rfc/template
which I thought was better, so I added this to the template:

    ## Future Scope
    
    Were there any ideas or variations considered that seemed reasonable
    follow-ons from the initial suggestions, that we don't need to do now,
    but want to revisit in the future? If there are parts of the design
    marked as "intended for future expansion", then give an idea here of
    what direction is planned.


As for everything else, I'm not hung up on the names (or the details) - if
there's a better name we should use that instead.

Nicholas Clark

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