Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100355 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34743 invoked from network); 3 Sep 2017 07:17:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Sep 2017 07:17:13 -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:47489] helo=mx201.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 71/D3-04538-67CABA95 for ; Sun, 03 Sep 2017 03:17:11 -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 1doP9R-0004EO-OH; Sun, 03 Sep 2017 07:17:03 +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: Date: Sun, 3 Sep 2017 09:16:52 +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: <76EE812B-922D-46B4-8525-6AFA75843816@zend.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p13DlTxjmKxVlrQCG2DfgaVgs8X8COWjk" X-DNSBL-BARRACUDACENTRAL: YES X-DNSBL-PBLSPAMHAUS: YES Subject: Re: [PHP-DEV] [VOTE] UUID From: php@fleshgrinder.com (Fleshgrinder) --p13DlTxjmKxVlrQCG2DfgaVgs8X8COWjk Content-Type: multipart/mixed; boundary="im0UdeRgXbve47awaQW8bNWc9FGuLne7G"; protected-headers="v1" From: Fleshgrinder Reply-To: internals@lists.php.net To: Zeev Suraski , "internals@lists.php.net" Message-ID: Subject: Re: [PHP-DEV] [VOTE] UUID References: <9f09589f-0a8e-1b8c-7b4c-b7d6899ed4ab@fleshgrinder.com> <76EE812B-922D-46B4-8525-6AFA75843816@zend.com> In-Reply-To: <76EE812B-922D-46B4-8525-6AFA75843816@zend.com> --im0UdeRgXbve47awaQW8bNWc9FGuLne7G Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/2/2017 2:26 PM, Zeev Suraski wrote: >=20 >> On 2 Sep 2017, at 13:43, Fleshgrinder 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. >=20 > 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 p= ositive) - as long as they're ultimately represented on internals. >=20 > My quick search suggested there was only roughly two days worth of disc= ussion sometime in May, but it's possible I wasn't thorough in searching.= >=20 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= =2E 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. >=20 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 glo= bal class name that's not that unlikely to exist in apps and collide with= them (as opposed to, say, UUIDParseException). At minimum the comment a= bout the risk being very low, as well as the personal preference not to h= ave 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 U= UID class name is the right choice (if we pick the wrong choice of introd= ucing a class and not a function :-) but we should be accurate and upfron= t 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 perf= ormance is a weak argument (which is debatable), it's most certainly not = an inherently weak argument as the current wording implies. There should= n't be a ratified PHP RFC implying that performance considerations are we= ak 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 app= s, and taking them away or modifying them means substantial breakage. Th= e very introduction of the class, its name (and to a lesser degree its fu= nctionality) - are tickets with remarkably expensive cancelation options.= >=20 > Zeev >=20 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. --=20 Richard "Fleshgrinder" Fussenegger --im0UdeRgXbve47awaQW8bNWc9FGuLne7G-- --p13DlTxjmKxVlrQCG2DfgaVgs8X8COWjk 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 iQIcBAEBCAAGBQJZq6xtAAoJEOKkKcqFPVVr/vMQAMUIzuWi/0mvSD7Qs+LbT/Yj 0ojahrrhbxzsMaNbiWoj/ELZBxvWy6aLLPDeTWph77/GQUIwTyKsN3H+OWr0GZMA uRBDQQyoVsp4fb9e5VTPjDbpIClLXnmYHXHfZTrjdFSCEtpB9swhIPQC3DkNSHfJ 2OXYmJVEfy36Mc7jNfNGlvKjOXPOCzLQY9ks4l4Z1xzVjrfco4/vGsP3zIRPT/s2 qsDw1s3wmlQ4barwJlFsO11lbo9tJ/lBMkTP2H1jsDGm/V2bBVQk3sLMSc1G04GV crC81tvFH3rg83sixNbz684/Dwwjsk13To+BcjfKor19M6tIrA8z6XBr+KfJWikG J5tV45f9fg9Idl0a59Yrm0CHxUFzUkUOLEJhEFC5eLlJuENFU1glN+t6PtRJ29N6 7zlFydpjgaCdCzRBTwOEscLYZVzP4qYmyNKlRtSjvM7yNYeszLDMgHrgSxJOm7c1 iOmQXTMtbkaOsXpE59u+IH5RSfdVHWVLPbfKKVj9w7VRXFcDXhklCO16ZjbDn8gZ el0qr16eVUODtRYYQSR0RoWF1kqO97GfltCma9s/CNhWU7PqSfgAfQ6j+0xQs4Ir BjQ3r5PyASkXtGANJWDRnMeO+gpaIPakvsCebXyFZP5VUr5MbWKfC5hlKL8JOruB 6JAPN5o0gDwwi9LMsg9u =QP63 -----END PGP SIGNATURE----- --p13DlTxjmKxVlrQCG2DfgaVgs8X8COWjk--