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). 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. 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. 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. 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'.
To summarize - I'm strongly in favor of fixing this issue in PHP, but at the same time against the proposed solution. I'd vote in favor of something along the lines of uuid_v4_create() in a heartbeat. Zeev -----Original Message----- From: Fleshgrinder [mailto:p...@fleshgrinder.com] Sent: שבת 02 ספטמבר 2017 10:02 To: php-internals <internals@lists.php.net> Subject: [PHP-DEV] [VOTE] UUID Hello Internals! I just started the voting for the inclusion of a UUID value object in PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick the whole week. The voting is open starting now and until September 16. (2 weeks). -- Richard "Fleshgrinder" Fussenegger
