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. 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
signature.asc
Description: OpenPGP digital signature
