Re: [PHP-DEV] Guidelines for RFC post feature-freeze

This is only part of a thread. view whole thread
  115785
August 24, 2021 09:55 jordan.ledoux@gmail.com (Jordan LeDoux)
On Mon, Aug 23, 2021 at 11:09 PM Pierre Joye php@gmail.com> wrote:

> > Many additions went through while being incomplete. It was documented > so in the RFC but it does not make it a good thing. Many of them are > indeed much needed and related to features (some) PHP users have been > waiting for. Are they critical enough for the PHP usage to allow them > in while knowing it is not complete? For almost all recent RFCS > related to syntax, arguments/return types or properties, I don't think > it justifies being added while being incomplete. It is not critical > enough to the larger user base. It makes migration paths harder as > well. >
I just wanted to note that while this may be true, it's largely because RFC authors cannot reasonably create and pass RFCs which: 1. Are too large or complex for voters to make an informed decision about. 2. Include too many aspects which are controversial or which have strongly opposed viewpoints within the RFC voters. RFCs which do either of these two things cannot pass, therefore all RFCs which pass do neither. This will always result in RFCs which some people view as "incomplete". It's not because the RFC authors, or even the voters, forgot or "overlooked" something necessarily. It's simply a product of what the PHP voters value. Voters value backwards compatibility; voters value a strong use-case justification for a new feature; voters value consistency between existing language features and new language features. These are not bad things to value, and I don't see how you can expect RFC authors to avoid proposing features which some may see as incomplete. My operator overload RFC is something I've already put at least 100 hours into, it's trimmed down to a very limited set of operators with restrictions on certain implementations, I still have many more hours of work left on the implementation in order to make the necessary changes to opcodes for it, and it still will likely be something which there is significant resistance to. I might put in excess of 300-400 hours of work into this RFC only for it to be rejected because of differences of opinion on the feature. I would be very disappointed if I was able to successfully convince voters of the value of my contribution, address the concerns that were presented and find good compromises, and then be told that my work was faulty and incomplete because it only allows operator overload for objects instead of globally or doesn't allow overloading of the null coalesce operator, for instance. As long as RFC authors must lobby voters to get a feature included, there are features which will be cut in the interest of time, compromise, complexity, and comprehension. I don't see how you avoid that without abandoning the idea of voting altogether, which is something I'm sure we all find value in. Jordan
  115786
August 24, 2021 10:13 pierre.php@gmail.com (Pierre Joye)
Hi Jordan,

On Tue, Aug 24, 2021 at 4:55 PM Jordan LeDoux ledoux@gmail.com> wrote:

> 1. Are too large or complex for voters to make an informed decision about..
This is the real problem. Also you are correct on the cause (complexity of a topic), I don't think we are not able to understand complex RFCs.
> 2. Include too many aspects which are controversial or which have strongly opposed viewpoints within the RFC voters.
Incomplete implementation of a language construct is an order of magnitude worse than having to wait a bit longer.
> RFCs which do either of these two things cannot pass, therefore all RFCs which pass do neither.
Together with others I wrote the RFC RFC along with a few required after this. I fully grasp how hard it can be at times. However language constructs are not some random extensions we can drop, replace etc. They are basically there forever. And forever in my case is as long as PHP exists. What is one more year then? :)
> and new language features.
Which should be clearly complete to begin with, as much as possible. A hard to find agreement is not a good enough reason to push a new incomplete language feature, in my book. This is my only point.
> These are not bad things to value, and I don't see how you can expect RFC authors to avoid proposing features which some may see as incomplete. My operator overload RFC is something I've already put at least 100 hours into, it's trimmed down to a very limited set of operators with restrictions on certain implementations, I still have many more hours of work left on the implementation in order to make the necessary changes to opcodes for it, and it still will likely be something which there is significant resistance to.. I might put in excess of 300-400 hours of work into this RFC only for it to be rejected because of differences of opinion on the feature.
You most likely will, and we are all grateful for that. It also shows that such RFCs are not about a single individual. Language features are better designed, proposed or implemented by a group of persons. That's the tricky part but it may help a lot.
> > I would be very disappointed if I was able to successfully convince voters of the value of my contribution, address the concerns that were presented and find good compromises, and then be told that my work was faulty and incomplete because it only allows operator overload for objects instead of globally or doesn't allow overloading of the null coalesce operator, for instance.
I cannot say anything about it as I did not go through it deeply. However, yes, I would rather vote no on operator overloading not being fully documented in the RFC. I could imagine not every single case could go in the 1st round. While operators overloading add enough complexity already without having to think about where it will work and where not, as an end user. But the roadmap must then be clear, implementation etc. The idea of saying "let see later" is not a good way to accept language changes. Best, -- Pierre @pierrejoye | http://www.libgd.org
  115790
August 24, 2021 18:43 Danack@basereality.com (Dan Ackroyd)
Pierre Joye wrote:
> Many additions went through while being incomplete. > ... > For almost all recent RFCS > related to syntax, arguments/return types or properties, I don't think > it justifies being added while being incomplete.
I think you are remembering how changes were made to PHP through rose tinted glasses. Pretty much all of the improvements to PHP's type system were 'incomplete' but they were still huge chunks of work, and some of them only just got accepted. Suggesting that (other) people need to do more work to satisfy the level of quality you want in an RFC is a good way of stopping any major progress from being achieved. Seeing as a lot of RFCs that improve PHP's type system seem to be the last RFC before someone decides to not bother contributing any more, I strongly suggest not trying to make it more difficult to get improvements made. Pierre Joye wrote:
> A library or framework (main users of most of these features) may or > may not implement the given addition, requiring say 8.1, and yet again > require 8.2 .... > > What is one more year then? :)
If a library thinks a feature is 'incomplete' they can hold off using it, while other people who think it's useful enough can use it earlier. After all, what is one more year then? Pierre Joye wrote:
> I don't think we are not able to understand complex RFCs.
The intersection types RFC was pretty clear that it didn't support union types. This limitation could have been discussed as part of the RFC discussion, and George would have explained his choice, namely that implementing the RFC was going to be difficult and so he wanted to limit the scope of the RFC*. The fact that this limitation in scope apparently wasn't understood by some people who apparently have strong feelings about it, suggests that people don't always understand what is being discussed or voted on. Tobias Nyholm wrote:
> then the discussion and the vote should not consider “if it is too late” > or “this is rushed”.
This is a really bad idea. Previously (but not recently), some of the more heated RFC discussions moved from being about the RFC to being about what are "right" and "wrong" reasons for voting. That type of discussion very quickly descends into either name calling, or people just refusing to take part in discussions. If nothing else, how would you 'prove' that someone has voted for the 'wrong reason', and so needs to have their vote discounted? cheers Dan Ack * To be clear, the implementation was very difficult, and George spent a huge amount of time on it. I suggest reviewing the implementation if you aren't familiar with it: https://github.com/php/php-src/commit/069a9fa5e4478c7044cb6432258cfe207d10a202 and definitely before saying that leaving out union types was an 'oversight'.
  115793
August 24, 2021 19:02 pierre.php@gmail.com (Pierre Joye)
good evening Dan,

First of all, could you please not merge  many different mails in one
single reply? Thanks.


On Wed, Aug 25, 2021, 1:43 AM Dan Ackroyd <Danack@basereality.com> wrote:

> Pierre Joye wrote: > > Many additions went through while being incomplete. > >
> For almost all recent RFCS > > related to syntax, arguments/return types or properties, I don't think > > it justifies being added while being incomplete. > > I think you are remembering how changes were made to PHP through rose > tinted glasses. >
Not really, or actually not at all. Quite the opposite. Pretty much all of the improvements to PHP's type system were
> 'incomplete' but they were still huge chunks of work, and some of them > only just got accepted.
This implies that this statement is more accurate than the one in my reply. Suggesting that (other) people need to do more work to satisfy the
> level of quality you want in an RFC is a good way of stopping any > major progress from being achieved. >
I think there is a misunderstanding here. PHP is not at a stage where what is missing are easy additions like simple scalar return types. As the recent discussions show, it needs more time to design, plan and implement the desired additions. This is why so many languages having reached this level of maturity are extremely prudent when it comes to very long term syntax or features additions. Seeing as a lot of RFCs that improve PHP's type system seem to be the
> last RFC before someone decides to not bother contributing any more, I > strongly suggest not trying to make it more difficult to get > improvements made. >
I understand your concerns and similar concerns have been brought when we introduced, you guess it, the RFC process. What I am talking about here is to have more clarity and stability how such critical additions are approved, or not. Critical not because of the needs but the permanent state of such additions. And more importantly, how they are designed to begin with. This is rarely a short journey nor a one person show. It is hard to have a diverse group with enough time, knowledge and motivation to work on such ungrateful tasks (but challenging). Such events create exactly what your comment is saying. best, Pierre
  115882
August 27, 2021 17:39 Danack@basereality.com (Dan Ackroyd)
On Tue, 24 Aug 2021 at 20:02, Pierre Joye php@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
  115891
August 28, 2021 07:54 pierre.php@gmail.com (Pierre Joye)
On Sat, Aug 28, 2021, 12:39 AM Dan Ackroyd <Danack@basereality.com> wrote:

> On Tue, 24 Aug 2021 at 20:02, Pierre Joye php@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. >
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md https://www.php.net/mailing-lists.php please note that nowhere in these rules there is plural being used for the mail's author you are going to reply to. This is also a very common, wide spread, netiquette across almost all MLs I use. So. That's it. Rest is not relevant anymore. There is no point to split hairs any longer.
>