On Sun, Jun 16, 2024, at 10:33, Rowan Tommins [IMSoP] wrote: > > > On 16 June 2024 03:00:39 BST, "Marco Aurélio Deleu" <deleu...@gmail.com> > wrote: > >If you appoint a different jury to try a 20 year old case, the decision of > >the previous jury doesn't have any more weight than any other evidence on > >its own. > > You missed the point of the analogy. The point is that that would only > happen if you have some specific reason why the case needs to be reopened. > > I'm not saying nobody is allowed to talk about this. I'm just saying, let's > start by looking at the old discussion, and discuss *specifically* what might > have changed, rather than waving our hands and saying "10 years is a long > time, so no opinion from that long ago can possibly be valid". > > > >You may have core developers that voted no due to maintenance burden, but if > >said maintainer is no longer active and new maintainers don't mind it, it's > >a moot argument because people changed. > > The maintenance burden argument is actually a good example of *not* being > about individuals. The argument is not "I don't want to maintain it", it's > "we shouldn't burden future maintainers with this". > > > >You may have no votes casted because at the time PHP technical debt couldn't > >cope with such a change, which maybe isn't relevant anymore because the > >project evolved. > > This, on the other hand, is a good example of one where we don't need to > guess. Look at the archives - were people concerned about the implementation? > If so, pointing out that the implementation would now be simpler would > absolutely be a reason to bring it back to discussion. > > > >You may have community leaders voting no because they inherently disagree > >with the concept but if they have moved on to other endeavors and current > >PHP community members like the concept, then society changes play a vital > >role in a different outcome. > > Again, let's stop talking in the abstract, and look at this specific case. > Can you point to changes in the usage of PHP that make this feature more > likely to see wide use or acceptance? Do you think the community at large, > who we are trying to represent here, is more or less likely to write a purely > static class in 2024 than in 2014? > > > All I'm asking is that if we are going to revisit features we previously > rejected, we start with "here's why I think the arguments for and against > this feature have changed", rather than "I don't like the old result, I > demand a new vote". > > Regards, > Rowan Tommins > [IMSoP] >
I don’t understand why we are comparing this to a jury and/or court case. In many countries, juries don’t even exist (such as the one I currently reside in) so the only context is US TV shows for what that even means. Secondly, RFC’s are not “on trial” and can be presented over and over again without much change. To say “go read the history” is a cop out. If it keeps coming up, by random individuals, then there is clearly enough demand that people would go through the challenge of arriving here and presenting it. Even if it is the hundredth time, those people deserve our respect to at least copy and paste our previous emails instead of sending them on a wild goose chase. I did go back and read them, and the original from 10 years ago was so convoluted it wasn’t even worth it. The one from Lanre was basically kicked (possibly by a vocal minority) for people not understanding the value, not because the idea was invalid. Here we are, another person who may present it differently to help you understand the value. I understand the value, though I don’t agree with it. If I could vote, I would vote yes; even if I never used it because I understand how it would be used and its usefulness for certain types of projects (I’ve def used this sort of pattern on single-file proof of concepts). To Lanre and Bilge, good luck! From watching this list for the last few years, many people won’t contribute to the conversation until there is a real RFC/implementation to discuss. It may be worth teaming up. ;) — Rob
