Re: [RFC] [VOTE] Deprecations for PHP 8.4

From: Date: Wed, 31 Jul 2024 01:07:57 +0000
Subject: Re: [RFC] [VOTE] Deprecations for PHP 8.4
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
> On Jul 30, 2024, at 4:26 PM, Tim Düsterhus <[email protected]> wrote:
> The problem with adding standalone functions for every algorithm is that it would result in a
> combinatorial explosion of available functions.

I commented on this but as it was probably missed in a longer reply so I will repeat.

There is no overwhelming benefit to having a dedicated function for *every* combination. However I
can see a benefits to having a dedicated function for the most commonly used functions.

To decide which, follow the Pareto principle where ~20% of functions used ~80% of the time get their
own function. Deciding which are the 20% can be determined by statistical analysis of public code
bases, or where there is no existing evidence for new functionality, by voters opinions.

-Mike

P.S. BTW, I do acknowledge your earlier point about more functions == more documentation — the
first I've heard anyone mention that, so kudos for shining a light on it — but I wonder if
that effort might not be reduced by finding ways to shared duplicated information from a single
source?

Maybe one way to address the effort required for docs is to provide incentive that could shift some
of the burden of documentation onto those who want to see more added to core?  Maybe:

1.) Encourage docs to be prewritten for RFCs calling for more functions, to motivate people to do
the docs work up-front by having a policy to vote against RFCs without pre-written docs, 

2.) Provide a prominent TODO queue of doc items needed with good-first-task tags that you can point
people to on the list who argue for things requiring a lot of documentation while saying "Well,
if you can't be bothered to update the current docs how do we know you'll help maintain
the docs for what you are asking for?" (admittedly this would probably take a bit of coding to
implement), 

3.) And finally host one or more "How to write docs for PHP" Zoom sessions that get
recorded and posted to YouTube to empower more people to know how to do it and to provide links for
discussions where you call for help 

(I, for one, really have no idea how to get started helping to clean up the docs, nor do I have any
idea where the most need is.)

#jmtcw


Thread (97 messages)

« previous php.internals (#124696) next »