Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100354
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 104.47.36.98 cause and error)
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [VOTE] UUID
Thread-Index: AQHTI7l6xf5xAadSwkqa7tWDxIIW46KhW7VAgAANYICAABzKRQ==
Date: Sat, 2 Sep 2017 12:26:11 +0000
Message-ID: <76EE812B-922D-46B4-8525-6AFA75843816@zend.com>
References: <b92961d5-a34f-737b-896b-0d63da0f7f6b@fleshgrinder.com>
 <BY2PR02MB298C0B77E3C66533DA9F8BBAC930@BY2PR02MB298.namprd02.prod.outlook.com>,<9f09589f-0a8e-1b8c-7b4c-b7d6899ed4ab@fleshgrinder.com>
In-Reply-To: <9f09589f-0a8e-1b8c-7b4c-b7d6899ed4ab@fleshgrinder.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2017 12:26:11.1614
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR02MB1623
Subject: Re: [PHP-DEV] [VOTE] UUID
From: zeev@zend.com (Zeev Suraski)


> On 2 Sep 2017, at 13:43, Fleshgrinder <php@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:
>>=20
>> 0. I agree with the premise of the RFC, that we should have something be=
tter than uniqid() built into the language.
>> 1. I think a renewed discussion, beyond the two days of discussion 3+ mo=
nths ago would be useful, as beyond that basic (yet important) point - I ha=
ve thoughts about a bunch of things in the RFC, and honestly didn't even no=
tice the brief discussion months ago (if there was another one then my apol=
ogies, I couldn't find it).
>=20
> 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 positiv=
e) - as long as they're ultimately represented on internals.

My quick search suggested there was only roughly two days worth of discussi=
on sometime in May, but it's possible I wasn't thorough in searching.

>=20
>> 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/obje=
cts in such a case - where there's little to no added value, is wrong and u=
ncommon (possibly unprecedented) in PHP.
>=20
> DateTime? SPL? Intl?

Not really - all of those give substantial value that can't really be provi=
ded 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 theref=
ore not a good candidate for mandatory object wrapping.

>=20
>> 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, whic=
h might collide with user defined classes of the same name in the global na=
mespace. 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 userb=
ase.  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 mi=
ght 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 in=
troducing - at least the UUID class - is very low.  Not that I have a bette=
r suggestion (other than not introducing a class at all) - but I think the =
text there should be changed as it does not reflect reality.
>=20
> 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 ove=
rkill.  But UUID isn't just a global class name - it's actually a global cl=
ass name that's not that unlikely to exist in apps and collide with them (a=
s opposed to, say, UUIDParseException).  At minimum the comment about the r=
isk being very low, as well as the personal preference not to have user cla=
sses 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 i=
s 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.
>=20
>=20
>> 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 absolute=
ly matters.  If we manage to get JIT out the door and the performance diffe=
rences become negligible - then I see a lot of value in moving some of our =
core value to PHP - but not before then.
>=20
> 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 performa=
nce is a weak argument (which is debatable), it's most certainly not an inh=
erently weak argument as the current wording implies.  There shouldn't be a=
 ratified PHP RFC implying that performance considerations are weak argumen=
ts, without clear context and explanation.
>=20
>> On 9/2/2017 12:14 PM, Zeev Suraski wrote:
>> 5.  Given we seem to agree this is a basic building block of the languag=
e (as it is in other languages), I do think it should be a 2/3 majority vot=
e 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'.
>=20
> 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, a=
nd taking them away or modifying them means substantial breakage.  The very=
 introduction of the class, its name (and to a lesser degree its functional=
ity) - are tickets with remarkably expensive cancelation options.

Zeev