> On 2 Sep 2017, at 13:43, Fleshgrinder <p...@fleshgrinder.com> wrote:
> On 9/2/2017 12:14 PM, Zeev Suraski wrote: >> I just voted 'no', and I'd like to quickly explain why: >> >> 0. I agree with the premise of the RFC, that we should have something better >> than uniqid() built into the language. >> 1. I think a renewed discussion, beyond the two days of discussion 3+ months >> ago would be useful, as beyond that basic (yet important) point - I have >> thoughts about a bunch of things in the RFC, and honestly didn't even notice >> the brief discussion months ago (if there was another one then my apologies, >> I couldn't find it). > > 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. > >> On 9/2/2017 12:14 PM, Zeev Suraski wrote: >> 2. I think that a function that returns a string (a-la uuid_v4_create() >> Nikita proposed) would make perfect sense. Forcing the use of >> classes/objects in such a case - where there's little to no added value, is >> wrong and uncommon (possibly unprecedented) in PHP. > > DateTime? SPL? Intl? 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. > >> On 9/2/2017 12:14 PM, Zeev Suraski wrote: >> 3. The section dealing with backwards incompatible changes, states: >> "Both UUID and UUIDParseException are now globally defined classes, which >> might collide with user defined classes of the same name in the global >> namespace. However, the risk of the introduction of them is considered to be >> very low, since the global namespace should not be used by PHP users." >> ... erroneously assumes that all code in PHP utilizes namespaces. IMHO this >> is a projection of a particular coding style onto the entire PHP userbase. >> We haven't deprecated at any point the ability to place user classes in the >> global namespace, we haven't even as much as said at any point we might be >> considering it - and I don't think we should, either. My gut feel, backed >> by a quick Google search refutes the assumption that the risk of introducing >> - at least the UUID class - is very low. Not that I have a better >> suggestion (other than not introducing a class at all) - but I think the >> text there should be changed as it does not reflect reality. > > The very same would be true for any function that is being introduced in > the global namespace. I had an RFC for namespaces prepared and ready for > vote; incl. a namespaced UUID implementation. However, the feedback on > it was so extremely negative and hostile that I decided to withdraw it. 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. > > >> On 9/2/2017 12:14 PM, Zeev Suraski wrote: >> 4. If I voted yes, it would also mean I agree with a statement such as "One >> could argue that it is faster (C implementation), which it probably is, but >> this is a weak argument". I disagree it's a weak argument - and I do think >> that for basic building blocks of the language, performance absolutely >> matters. If we manage to get JIT out the door and the performance >> differences become negligible - then I see a lot of value in moving some of >> our core value to PHP - but not before then. > > I would agree, but most people think differently. The wording is a > result of the discussions. 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. > >> On 9/2/2017 12:14 PM, Zeev Suraski wrote: >> 5. Given we seem to agree this is a basic building block of the language >> (as it is in other languages), I do think it should be a 2/3 majority vote >> and not a 50%+1 one. Taking the "is this something we can easily change w/o >> affecting BC" test, this clearly gets a 'no'. > > Actually we can. Both classes are final and users cannot extend them. > The only thing we cannot do is rename the stuff that's already in them. > This is one of the reasons why I kept the provided functionality to a > bare minimum. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
