Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100389 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36738 invoked from network); 5 Sep 2017 17:24:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Sep 2017 17:24:54 -0000 Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.122 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 212.232.28.122 mx201.easyname.com Received: from [212.232.28.122] ([212.232.28.122:38198] helo=mx201.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 76/E9-04538-5EDDEA95 for ; Tue, 05 Sep 2017 13:24:54 -0400 Received: from cable-81-173-135-10.netcologne.de ([81.173.135.10] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dpHag-0004W1-Vl; Tue, 05 Sep 2017 17:24:48 +0000 Reply-To: internals@lists.php.net To: Zeev Suraski , "internals@lists.php.net" References: <9f09589f-0a8e-1b8c-7b4c-b7d6899ed4ab@fleshgrinder.com> <76EE812B-922D-46B4-8525-6AFA75843816@zend.com> Message-ID: <97cdbf8a-68b5-9cbf-ee99-47d55ae88fb6@fleshgrinder.com> Date: Tue, 5 Sep 2017 19:24:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mHWnqfxrkaL41arINadbgthMqDicTv3UR" X-DNSBL-BARRACUDACENTRAL: YES X-DNSBL-PBLSPAMHAUS: YES Subject: Re: [PHP-DEV] [VOTE] UUID From: php@fleshgrinder.com (Fleshgrinder) --mHWnqfxrkaL41arINadbgthMqDicTv3UR Content-Type: multipart/mixed; boundary="UivQUiDA98kcxPAELcqxjSVfCBK4O1w37"; protected-headers="v1" From: Fleshgrinder Reply-To: internals@lists.php.net To: Zeev Suraski , "internals@lists.php.net" Message-ID: <97cdbf8a-68b5-9cbf-ee99-47d55ae88fb6@fleshgrinder.com> Subject: Re: [PHP-DEV] [VOTE] UUID References: <9f09589f-0a8e-1b8c-7b4c-b7d6899ed4ab@fleshgrinder.com> <76EE812B-922D-46B4-8525-6AFA75843816@zend.com> In-Reply-To: --UivQUiDA98kcxPAELcqxjSVfCBK4O1w37 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/4/2017 11:04 AM, Zeev Suraski wrote: > Richard, >=20 > 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 a= lthough at this point I don't think I did, that's still a possibility. >=20 Sorry, than I misunderstood. I interpreted it in the way that you meant that I did something wrong by bringing this to vote. On 9/4/2017 11:04 AM, Zeev Suraski wrote: > My point is simple - when I saw the vote, I looked for the prior discus= sion on internals - which is the *only* official channel for discussing t= hese 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 raise= d good points which remained unanswered, and it died out very quickly wit= hout 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. >=20 Maybe I should stop the vote. The discussion is happening now instead of before when I asked for it. We'll have to wait for at least six months for another vote if this is a no, due to the rules. On 9/4/2017 11:04 AM, Zeev Suraski wrote: > That's great, but given that it's unprecedented, it's not a very good a= rgument. To quote Marco from the May discussion: > "Introducing a UUID class in PHP core as *just* a type safety wrapper f= eels akin to adding an EmailAddress class to core. It's certainly not an = unreasonable way to handle things, but imho also not something that shoul= d 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." >=20 I disagree with that comment. I think that PHP is a high-level language, and thus should provide high-level abstractions that fulfill the most basic needs. A UUID is not a string, I'll go into this below. On 9/4/2017 11:04 AM, Zeev Suraski wrote: > There's a difference between certain people saying something, and 'most= people think'. There were only about 15 people that participated in thi= s 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. =20 >=20 > I could find some that said the opposite, including Ben Ramsey: > "A UUID generator in the core will only help to improve ramsey/uuid, pr= oviding more choice and better performance." > The 'only' there might be confusing, but it's intended in a positive wa= y. >=20 > 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. >=20 That was probably on some other channel. As I said, I'm more than happy to change that wording. =3D) On 9/4/2017 11:04 AM, Zeev Suraski wrote: > First, I do not prefer procedural programming. Personally I use OO a l= ot 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 languag= e. 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 a= cross the board, catering to the wide range of users in our community, an= d not half baked according to the individual preferences of the subsets o= f 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 no= t wanting to introduce a procedural API for creating a UUID. The procedu= ral/OO duality is not at all what people complain about when griping abou= t PHP's API mess. > Last, yes, the rationale is indeed true for most additions to the langu= age. The 2/3 barrier, as is explained in the Voting RFC (wiki.php.net/rf= c/voting), has a rationale - the rationale being that unlike changes in a= pps or frameworks, changes to the language have an immense cost of revers= al or incompatible alteration. Adding a top level object that's four let= ters long falls squarely within that definition - unlike, say, deciding w= hen 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 t= he current UUID proposal is accepted as-is, would we feel comfortable dep= recating it with 50%+1 majority? If the answer's no, introducing it shou= ldn't be at 50%+1 either. >=20 > Zeev >=20 >=20 I'm not going to propose a procedural API, because I truly believe that it is the wrong abstraction for the problem. You, or anyone else with the required Karma, can however propose a procedural API in a separate RFC. I cannot do anything against that, and that is good and fine. However, there is nothing that requires that I do that if I believe that it is wrong. A UUID is not a string, it is a 128 bit integer as defined in RFC 4112. The string forms are meant for human readability, and serialization only, not for dealing with them in a program. The first question that we would need to answer would be then, what should `uuid_vx_create` return? The binary form? The hex form? The string form? No clue to be honest. Let's say we return the string form, because it is immediately readable for anyone if printed. How do I get the hex version of it? Dedicated function again? How do I get the binary version of it? Dedicated function again? Or maybe require people to use Composer, and search for a package on their own? Then again, it's totally simple. `str_replace('-', '', $uuid)` and you have your hex version, now just add a `hex2bin($hex)` to that result, and you're good to go. Should we add that to the documentation? Should we keep it a secret, and everybody needs to learn that on their ow= n? The latter is how it is done in C. A low-level language. Is PHP a low-level language? I do not think so. Another issue with the whole thing is with passing that UUID around. People have to validate the string everywhere. Hence, we need a `uuid_parse` or `uuid_is_valid` function. Or should we again recommend Composer? Then again, is Composer part of PHP? I hope you're still with me. What I want to say is, that a procedural approach comes with more questions than answers. A class can provide all of this at once. People can decide what they want, binary, hex, or string. We do not have to make that decision for them! The proposed UUID class is smaller than the one in Java, Rust, Python, =2E.. I made sure of that. I made sure that it has the least impact, as well as the least complexity possible. While still providing the ability to accommodate almost all needs. Doing exactly the same with a procedural API that covers all the same use-cases would be much harder. This might have to do with personal preference as well. However, I think that you can only design something good in the way you prefer it. I do not believe that people who never create procedural APIs are good at it. They lack the knowledge in doing so. The same is true for designing a purely functional API, I would not be good at it. Hence, me proposing a pure procedural API might lead to a bad API. I would like to add that PHP not only historically has bad APIs. We just added the Sodium extension which has a horrible and confusing API as well. I complained about this, its still being merged. There are already thread popping up on Reddit about it ... it was added a few days ago. That is sad, that makes me sad, ... I understand now why the PHP-FIG was initiated, those people probably had comparable issues with PHP. I joined internals because I want to help, I want to help with getting in stuff that is actually useful for all web developers out there. A dedicated UUID structure is one such small thing. A UUID string is not, because it creates more problems than it solves. Probably spawning a PSR for UUIDs, with an interface and two hundred implementations, where the one is more over-engineered than the other. I say let us fix this for once, and be done with it. I gladly stop the vote, to ensure that the UUID topic is not blocked for 6 months. I will not provide a procedural API, because of the points made. However, anyone is free to pick my code and provide one. Anyone is free to propose the PECL version, which is already procedural (well, it works only on Linux). I'm, however, open to change the API to accommodate all valid points raised; like Nikic did and does on GitHub. I actually already addressed many issues based on his and the feedback of others on GitHub. --=20 Richard "Fleshgrinder" Fussenegger --UivQUiDA98kcxPAELcqxjSVfCBK4O1w37-- --mHWnqfxrkaL41arINadbgthMqDicTv3UR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZrt3VAAoJEOKkKcqFPVVrsjQP/ixh6TBMl7qIOAyH5OjM/CY6 IgTUJal4MOHSH8smz6NFjvmm58oR9mSVHm52Q1OHLVVQ9wAO7LhQtywXIz00Nyda a4ZQgtaGjM+rwJmxdRIaYuvhJltkrhCgCpGP4a/AoPfU6lR5mPJ3kLyE1RxgKtjW UkRE3a26KrF5Tz+ckSt5pHqU66fqDRNnmGgtz00bkkxiwwnPP/wLpPIpEnHaUB+c Qs2VSAtN1Hu+T7HVBqNPnT1k6mr5rbROOqsJLXrGYDi80ohci9jxdAKEGpk2uSvL tDKTWsl9xcyc7dB25WJWDmeMuKze9zpw/dYaSO/Xkafcr02aDDhQ81RLgk9i1kg5 uzhEQ6FgHTLq9WKO4uc6JDE/IL5RbHjz40LtuVLByp0vNd4NjNSEhii8R9VU2QHJ V/OfEZACp1bTI7Z5DinKEqiuJf4KcbmqTZ1DrX0eIeZTNo+2LOuFGIfZhy+1n/kl BfYjkri1oUS++YzjlknhNVZ0yz5rKP30+kIhTwajL7GXYgPK+se1U4rqdkq+YV7L BRttsMypAAuklrAibk9zkrzLc9NJSk6ceVH/enm+AqDVvvk/0tKN93mXTkHmQa3U uc4M2ZKTKNMqD1D+9pa+6TmiLmUDaMqsfuBG3oPCbOqoTQCNfgupaH4Im15wNM0b lTLQy2vD1I9Sioy6N4c8 =Bq6c -----END PGP SIGNATURE----- --mHWnqfxrkaL41arINadbgthMqDicTv3UR--