Hey Zeev, My issue with having more core classes is just with the fact that reflection and type system are not working 1:1 like in userland. Richard fixed that in the PR with extensive testing, so that's fine.
More type safety is definitely a good thing, especially when widely distributed. Passing around a UUID as a string is surely not something I'd allow in any kind of codebase I work with: it would be nuked at review. On 4 Sep 2017 11:04, "Zeev Suraski" <z...@zend.com> wrote: > > -----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 > > >
