> -----Original Message----- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Sunday, September 3, 2017 10:17 AM > To: Zeev Suraski <z...@zend.com>; internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] UUID > > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > > >> On 2 Sep 2017, at 13:43, Fleshgrinder <p...@fleshgrinder.com> wrote: > >> The discussion was really ongoing for a long time, and actually very > >> heated as well. It was on GitHub with lots of comments, Internals, > >> Reddit, Twitter, ... everywhere. > > > > As far as I'm concerned the only relevant discussion is on internals. It's > > ok to > use other mediums (although personally I think it's not very positive) - as > long > as they're ultimately represented on internals. > > > > My quick search suggested there was only roughly two days worth of > discussion sometime in May, but it's possible I wasn't thorough in searching. > > > > What I wanted to say is that the discussion was not held secretly, on the > contrary, it was very loud on many channels. I am not sure what you want from > me, because everything followed the officially prescribed procedures. Not sure > if I can be blamed that some people missed it. I asked for additional feedback > not two weeks ago before I started the vote.
Richard, I'm not accusing you of anything. This is all in positive constructive spirit, and I was the first to admit I may have missed something - and although at this point I don't think I did, that's still a possibility. My point is simple - when I saw the vote, I looked for the prior discussion on internals - which is the *only* official channel for discussing these matters. The only discussion I could find took place between May 24 and May 26 - i.e. well over 3 months ago. While being intense, it raised good points which remained unanswered, and it died out very quickly without any sort of followup. Again, I have no idea what kind of discussion happened on reddit or IRC or other channels, but that shouldn't matter. > Type safety alone is such a substantial value to me, and many others, that it > is > reason enough to go for the class. This is also my argument in the RFC, and I > stand by it. That's great, but given that it's unprecedented, it's not a very good argument. To quote Marco from the May discussion: "Introducing a UUID class in PHP core as *just* a type safety wrapper feels akin to adding an EmailAddress class to core. It's certainly not an unreasonable way to handle things, but imho also not something that should be in core. We should be providing the primitives based on which people can implement whichever abstractions they prefer, in a simpler and more flexible manner than we can achieve in extension code." > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > Where's the poll / vote that most people think differently? > > Either way, even if it can be argued that for this particular case > > performance > is a weak argument (which is debatable), it's most certainly not an inherently > weak argument as the current wording implies. There shouldn't be a ratified > PHP RFC implying that performance considerations are weak arguments, > without clear context and explanation. > > The people were the ones here on Internals. Read the discussion thread again. > I > gladly change the wording, because I also think that performance is a valid > argument, but did not feel like it would be accepted. Hence, the wording. There's a difference between certain people saying something, and 'most people think'. There were only about 15 people that participated in this thread, and of those, I couldn't find any that said that performance is a weak argument. Most didn't comment about performance at all. I could find some that said the opposite, including Ben Ramsey: "A UUID generator in the core will only help to improve ramsey/uuid, providing more choice and better performance." The 'only' there might be confusing, but it's intended in a positive way. I fail to see how it's possible to derive from that thread a statement that 'performance is a weak argument', and I do think it's bad to have a ratified php.net RFC that would make that statement as if it's an obvious truth. > > Regardless of being final, they'll become a basic building block in apps, > > and > taking them away or modifying them means substantial breakage. The very > introduction of the class, its name (and to a lesser degree its > functionality) - are > tickets with remarkably expensive cancelation options. > > > > Zeev > > > > This is true for any addition to the language, and imho not an argument > against > the inclusion of new features. I did my very best to create a good API that is > useful in daily life. I understand that you prefer procedural programming, > and I > understand that you do not see the value of type safety. I prefer OO, like the > majority of today's PHP community, and I prefer type safety, and the > implementation is the result of these preferences. Feel free to create > procedural aliases, like we have it for almost all other classes in core. I > think > one way to do things is better, but I also know that this is not the PHP way. > Confusing APIs and multiple ways to do the same thing is the status quo. I > believe we should break out of that, and cleanup, but many others don't ... > alas. > Another reason to leave PHP behind. First, I do not prefer procedural programming. Personally I use OO a lot more than I use procedural. This is, however, completely besides the point - when designing and maintaining PHP, I put my personal preferences aside and try to think about what's right and consistent for the language. I think everyone who contributes should do the same. Secondly, and very much related, suggesting "I'll do half the job, you can do the other half if you want" is very much the wrong approach IMHO. When introducing a new feature, we should strive to make it consistent across the board, catering to the wide range of users in our community, and not half baked according to the individual preferences of the subsets of the language one likes. Thirdly, there's nothing inherently confusing about procedural APIs, or inherently clear about OO APIs. Yes, some of our legacy APIs are a mess, and it's a tough problem to tackle - but this has nothing to do with not wanting to introduce a procedural API for creating a UUID. The procedural/OO duality is not at all what people complain about when griping about PHP's API mess. Last, yes, the rationale is indeed true for most additions to the language. The 2/3 barrier, as is explained in the Voting RFC (wiki.php.net/rfc/voting), has a rationale - the rationale being that unlike changes in apps or frameworks, changes to the language have an immense cost of reversal or incompatible alteration. Adding a top level object that's four letters long falls squarely within that definition - unlike, say, deciding when to release version X, or whether to call version Y "8.0" or "10.0". Looking at it from the other end - fast forward into 2021 a world where the current UUID proposal is accepted as-is, would we feel comfortable deprecating it with 50%+1 majority? If the answer's no, introducing it shouldn't be at 50%+1 either. Zeev
