Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100356
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.174 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>, Zeev Suraski
	<zeev@zend.com>, "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [VOTE] UUID
Thread-Index: AWJkNjc15jo9YtdWYNBXrhY8TI8n6DA4NTdCYjg0MWbc7b01NQ==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sun, 3 Sep 2017 17:02:47 +0000
Message-ID:
	<CY1PR03MB1503C56B9220D8D4EFE12676F2900@CY1PR03MB1503.namprd03.prod.outlook.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>
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative;
	boundary="_000_CY1PR03MB1503C56B9220D8D4EFE12676F2900CY1PR03MB1503namp_"
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [VOTE] UUID
From: andigutmans@gmail.com (Andi Gutmans)

--_000_CY1PR03MB1503C56B9220D8D4EFE12676F2900CY1PR03MB1503namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Why would we not just add this under Spl? Feels like an appropriate place t=
o put standard methods.
I would definitely not make functionality like this a top level class/names=
pace both for BC reasons and it is a minor capability that fits in well int=
o a standard library context.

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Fleshgrinder <php@fleshgrinder.com>
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

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 bet=
ter than uniqid() built into the language.
> 1. I think a renewed discussion, beyond the two days of discussion 3+ mon=
ths ago would be useful, as beyond that basic (yet important) point - I hav=
e thoughts about a bunch of things in the RFC, and honestly didn't even not=
ice the brief discussion months ago (if there was another one then my apolo=
gies, 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.

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() N=
ikita proposed) would make perfect sense.  Forcing the use of classes/objec=
ts in such a case - where there's little to no added value, is wrong and un=
common (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

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 nam=
espace. However, the risk of the introduction of them is considered to be v=
ery low, since the global namespace should not be used by PHP users."
> ... erroneously assumes that all code in PHP utilizes namespaces.  IMHO t=
his is a projection of a particular coding style onto the entire PHP userba=
se.  We haven't deprecated at any point the ability to place user classes i=
n the global namespace, we haven't even as much as said at any point we mig=
ht 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 int=
roducing - 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 t=
ext 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.

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 absolutel=
y matters.  If we manage to get JIT out the door and the performance differ=
ences become negligible - then I see a lot of value in moving some of our c=
ore value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 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 somethin=
g along the lines of uuid_v4_create() in a heartbeat.
>

    $bin =3D \UUID::v4()->toBinary();
    $hex =3D \UUID::v4()->toHex();
    $str =3D \UUID::v4()->toString();

You can already use it like you want, with greater possibilities and
freedom. Incl. auto-completion with your favorite editor to explore your
possibilities, and type-safety everywhere as an opt-in.

--
Richard "Fleshgrinder" Fussenegger


--_000_CY1PR03MB1503C56B9220D8D4EFE12676F2900CY1PR03MB1503namp_--