On Tue, 24 Aug 2021 at 20:02, Pierre Joye <pierre....@gmail.com> wrote: > > good evening Dan, > > First of all, could you please not merge many different mails in one single > reply? Thanks.
No. This is a mailing list, where conversations get spread over different forks of threads. When a reply is relevant to multiple previous messages, it's better to combine them so people can see a complete message at once, rather than expecting people to read through multiple messages in the correct order, to understand what I'm saying. > PHP is not at a stage where what > is missing are easy additions like simple scalar return types. First, "simple scalar return types" was not an RFC, that is at least two RFCs or three: Return Type Declarations - https://wiki.php.net/rfc/return_types - 2014-03-20 Nullable Types - https://wiki.php.net/rfc/nullable_types - 2014-04-10 Scalar Type Declarations - https://wiki.php.net/rfc/scalar_type_hints_v5 - 2015-02-18 To me, this is a good example of how breaking large chunks of work is an effective strategy. Second, you are either completely forgetting or just denigrating the amount of work that was involved in getting scalar types passed. It was a shitshow of a discussion that took a huge amount of effort to get passed. Coming up with the technical details and implementing an RFC are only part of the process, and are the fun bit. But then after that any RFC author has to persuade the rest of PHP internals that it's a good idea. I talk to some of the people who do RFCs and one of the common things I hear is that listening to internals feedback is a hugely stressful and difficult thing to do. This may be different to when you last passed an RFC, at least in part because there are now relatively more people who don't commit to PHP-src frequently (or at all) taking part in discussions, and so RFC authors find it really hard to figure out which feedback should be listened to, and which feedback is less relevant. Although listening to user feedback can be useful, there is a lack of detailed technical feedback and help in implementing RFCs. > As the recent discussions show, it needs more time to design, > plan and implement the desired additions. Just saying people should work harder doesn't help. I'll agree that the project would be in a better place if there were more people making technical contributions but PHP is worked on by volunteers. But just having people show up after RFCs have been passed, and say "the work done isn't good enough" is completely disrespectful to the people who have been maintaining and improving PHP. I don't think a more difficult process is what the PHP project needs. Instead it needs more people able to, and willing to work on the code. One thing that might help with that is getting more sponsoring of people who have done work. I've made a list of RFC authors here: https://phpopendocs.com/sponsoring/internals sincerely Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
