On Thu, 9 Jul 2020 at 18:04, Larry Garfield <la...@garfieldtech.com> wrote: > > I've no idea what the rules are around new version numbers > of RFCs that haven't been up for a vote yet.
I pretty strongly recommend people against re-using documents. If it's going to change significantly, using a new doc makes it easier to see it's a different idea. Alternatively summarising the changes might be more appropriate for smaller changes. Larry wrote: > Which guidelines in particular bug you, and why? Just to note, my problem isn't just with the details, but to pick out a few. RFC text: > Any namespaced code provided by PHP-SRC will use a sub-namespace of \PHP. > That is, no PHP\Foo class may be defined, That seems like something that will have reasonable exceptions to. RFC text: > Classes that are part of a disable-able extension > Eg, \PHP\Sodium. I don't believe extensions should necessarily be under a PHP namespace. Instead that should be thought about case-by-case. Also, extensions can move from being one that can be disabled to not being disable-able. RFC text: > Upgrade path for existing classes > That is, a rename introduced in PHP 8.2 is not eligible to have its > old name removed until at least 10.0. The reason for having aliases is mostly to allow easier upgrading. i.e. i) User code runs on version x.y of PHP. ii) User code runs on version x.(y+1) of PHP. iii) The user changes any use of old names on x.(y+1). iv) Old names can be remove in version x.(y+2) Keeping aliases of old names around for longer than that isn't that useful. But again, this should be thought about case-by-case. Rowan Tommins wrote: > This is pure whataboutery; the idea that reading a few > naming conventions will be such a burden that somebody > would have no time to review a feature is frankly ridiculous. That's getting pretty close to just name-calling. It's fine to think that there is a problem here, and that adopting this RFC is an appropriate solution to that problem. But I think that there isn't really a problem to solve here, and that even if there is, solving it through an RFC is worse than just ignoring the problem. This difference in approach possibly comes from a difference in philosophy. aka I think we're both making sensible arguments, but based on different values of what is important, and so coming to different conclusions. I've recommended the book Systemantics before: https://en.wikipedia.org/wiki/Systemantics It has lots of very useful advice about the counter-intuitive results that emerge from decisions. And it's from that approach to systems design that I'm basing my thinking. One of the most simplest pieces of advice it gives is: "First rule of systems design: do without out one if possible" And one of the few pieces of advice that I give to people, that I'm pretty sure is right is: "Accept you're going to be wrong - Make it easier to correct mistakes." which was part of a whole talk I gave at DPC* I don't think this RFC provides much benefit now, and I don't think it makes it easier to name things in the future. In fact it makes things more difficult as any exceptions to the rules laid down in this RFC now become "DEVIATIONS FROM OUR ALREADY DECIDED RULES!!1!" rather than things that can be thought about as code, coding standards, and people's personal preferences all evolve. cheers Dan Ack * Video: https://www.youtube.com/watch?v=TS9BNa1MDW0 Slides: http://docs.basereality.com/GoodOrBad_DPC/ Apologies for the quality of my voice which made the presentation quality not as high as I had hoped. But it does lead to the 2nd piece of advice I'm pretty sure is correct, which is "wear a seatbelt so you don't damage your spine in a car crash" which might seem kind of obvious advice in retrospect. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
