Re: [VOTE] UUID

On 9/2/2017 2:26 PM, Zeev Suraski wrote: > >> On 2 Sep 2017, at 13:43, Fleshgrinder <php@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. On 9/2/2017 2:26 PM, Zeev Suraski wrote:> Not really - all of those give substantial value that can't really be provided without a class. Not so with UUID - I'm quite with Nikita when he says that 95% of the value can be had with a single function call - it's therefore not a good candidate for mandatory object wrapping. > 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. On 9/2/2017 2:26 PM, Zeev Suraski wrote: > Rightfully so - I don't think a UUID namespace is the answer as it's an overkill. > But UUID isn't just a global class name - it's actually a global class name that's > not that unlikely to exist in apps and collide with them (as opposed to, say, UUIDParseException). > At minimum the comment about the risk being very low, as well as the personal preference not to have > user classes in the global namespace should be removed, imho, even if we can't come up with a > better name. It may be that sticking with the UUID class name is the right choice (if we pick the > wrong choice of introducing a class and not a function :-) but we should be accurate and upfront as > to why we think it's ok. I did not propose a UUID namespace, that is what others from Internals wanted. My namespace proposal is much greater than that. However, the feedback was one-sided and hostile, so that I decided to withdraw the RFC, and seriously think about why I should continue contributing to PHP. https://wiki.php.net/rfc/namespaces-in-core 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. On 9/2/2017 2:26 PM, Zeev Suraski wrote: > 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. -- Richard "Fleshgrinder" Fussenegger

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc