[VOTE] UUID

  100347
September 2, 2017 07:01 Fleshgrinder <php@fleshgrinder.com>
--FEQcnDnaTFxLpmxHlLHkBGjFHwuooPKDj
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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).

--=20
Richard "Fleshgrinder" Fussenegger



--FEQcnDnaTFxLpmxHlLHkBGjFHwuooPKDj--
  100348
September 2, 2017 07:32 me@kelunik.com (Niklas Keller)
> > 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).
RFC: https://wiki.php.net/rfc/uuid
  100349
September 2, 2017 07:36 Fleshgrinder <php@fleshgrinder.com>
--32FLIKQrAeBLBKhm9pNBVWt4JExe8tBUn
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 9/2/2017 9:32 AM, Niklas Keller wrote:
>> >> 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). >=20 >=20 > RFC: https://wiki.php.net/rfc/uuid >=20
This is the second time that I forget the link, stupid me. Thanks a lot. = :) --=20 Richard "Fleshgrinder" Fussenegger --32FLIKQrAeBLBKhm9pNBVWt4JExe8tBUn--
  100350
September 2, 2017 10:14 zeev@zend.com (Zeev Suraski)
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:php@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
  100351
September 2, 2017 10:43 Fleshgrinder <php@fleshgrinder.com>
--0Oj97LkvT37jtdppwDBowlUAX7apPqHSu
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey Zeev :)

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 b= etter than uniqid() built into the language.
> 1. I think a renewed discussion, beyond the two days of discussion 3+ m= onths 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 ev= en notice the brief discussion months ago (if there was another one then = my apologies, 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()= Nikita proposed) would make perfect sense. Forcing the use of classes/o=
bjects in such a case - where there's little to no added value, is wrong = and uncommon (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, whi= ch might collide with user defined classes of the same name in the global=
namespace. However, the risk of the introduction of them is considered t= o be very low, since the global namespace should not be used by PHP users= =2E"
> ... erroneously assumes that all code in PHP utilizes namespaces. IMHO= this is a projection of a particular coding style onto the entire PHP us=
erbase. We haven't deprecated at any point the ability to place user cla= sses in the global namespace, we haven't even as much as said at any poin= t 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) - b= ut I think the text there should be changed as it does not reflect realit= y. 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 a= bsolutely matters. If we manage to get JIT out the door and the performa= nce differences become negligible - then I see a lot of value in moving s= ome of our core 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 langua= ge (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 ch= ange 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 a= t the same time against the proposed solution. I'd vote in favor of some=
thing along the lines of uuid_v4_create() in a heartbeat.
>=20
$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. --=20 Richard "Fleshgrinder" Fussenegger --0Oj97LkvT37jtdppwDBowlUAX7apPqHSu--
  100354
September 2, 2017 12:26 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: >> >> 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). > > 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 positive) - as long as they're ultimately represented on internals. My quick search suggested there was only roughly two days worth of discussion sometime in May, but it's possible I wasn't thorough in searching.
> >> 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/objects in such a case - where there's little to no added value, is wrong and uncommon (possibly unprecedented) in PHP. > > DateTime? SPL? Intl?
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.
> >> 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 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. > > 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 overkill. But UUID isn't just a global class name - it's actually a global class name that's not that unlikely to exist in apps and collide with them (as opposed to, say, UUIDParseException). At minimum the comment about the risk being very low, as well as the personal preference not to have 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 UUID class name is 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.
> > >> 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 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. > > 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 performance is a weak argument (which is debatable), it's most certainly not an inherently weak argument as the current wording implies. There shouldn't be a ratified PHP RFC implying that performance considerations are weak arguments, without clear context and explanation.
> >> 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.
Regardless of being final, they'll become a basic building block in apps, and taking them away or modifying them means substantial breakage. The very introduction of the class, its name (and to a lesser degree its functionality) - are tickets with remarkably expensive cancelation options. Zeev
  100355
September 3, 2017 07:16 Fleshgrinder <php@fleshgrinder.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 <php@fleshgrinder.com> 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--
  100365
September 4, 2017 09:04 zeev@zend.com (Zeev Suraski)
> -----Original Message----- > From: Fleshgrinder [mailto:php@fleshgrinder.com] > Sent: Sunday, September 3, 2017 10:17 AM > To: Zeev Suraski <zeev@zend.com>; internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] UUID > > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > > >> On 2 Sep 2017, at 13:43, Fleshgrinder <php@fleshgrinder.com> 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. > > > > 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 positive) - as long > as they're ultimately represented on internals. > > > > My quick search suggested there was only roughly two days worth of > discussion sometime in May, but it's possible I wasn't thorough in searching. > > > > 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.
Richard, 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 although at this point I don't think I did, that's still a possibility. My point is simple - when I saw the vote, I looked for the prior discussion on internals - which is the *only* official channel for discussing these 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 raised good points which remained unanswered, and it died out very quickly without 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.
> 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.
That's great, but given that it's unprecedented, it's not a very good argument. To quote Marco from the May discussion: "Introducing a UUID class in PHP core as *just* a type safety wrapper feels akin to adding an EmailAddress class to core. It's certainly not an unreasonable way to handle things, but imho also not something that should 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."
> 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 performance > is a weak argument (which is debatable), it's most certainly not an inherently > weak argument as the current wording implies. There shouldn't be a ratified > PHP RFC implying that performance considerations are weak 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.
There's a difference between certain people saying something, and 'most people think'. There were only about 15 people that participated in this 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. I could find some that said the opposite, including Ben Ramsey: "A UUID generator in the core will only help to improve ramsey/uuid, providing more choice and better performance." The 'only' there might be confusing, but it's intended in a positive way. 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.
> > Regardless of being final, they'll become a basic building block in apps, and > taking them away or modifying them means substantial breakage. The very > introduction of the class, its name (and to a lesser degree its functionality) - are > tickets with remarkably expensive cancelation options. > > > > Zeev > > > > 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.
First, I do not prefer procedural programming. Personally I use OO a lot 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 language. 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 across the board, catering to the wide range of users in our community, and not half baked according to the individual preferences of the subsets of 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 not wanting to introduce a procedural API for creating a UUID. The procedural/OO duality is not at all what people complain about when griping about PHP's API mess. Last, yes, the rationale is indeed true for most additions to the language. The 2/3 barrier, as is explained in the Voting RFC (wiki.php.net/rfc/voting), has a rationale - the rationale being that unlike changes in apps or frameworks, changes to the language have an immense cost of reversal or incompatible alteration. Adding a top level object that's four letters long falls squarely within that definition - unlike, say, deciding when 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 the current UUID proposal is accepted as-is, would we feel comfortable deprecating it with 50%+1 majority? If the answer's no, introducing it shouldn't be at 50%+1 either. Zeev
  100366
September 4, 2017 09:08 ocramius@gmail.com (Marco Pivetta)
Hey Zeev,

My issue with having more core classes is just with the fact that
reflection and type system are not working 1:1 like in userland. Richard
fixed that in the PR with extensive testing, so that's fine.

More type safety is definitely a good thing, especially when widely
distributed. Passing around a UUID as a string is surely not something I'd
allow in any kind of codebase I work with: it would be nuked at review.


On 4 Sep 2017 11:04, "Zeev Suraski" <zeev@zend.com> wrote:

> > -----Original Message----- > > From: Fleshgrinder [mailto:php@fleshgrinder.com] > > Sent: Sunday, September 3, 2017 10:17 AM > > To: Zeev Suraski <zeev@zend.com>; internals@lists.php.net > > Subject: Re: [PHP-DEV] [VOTE] UUID > > > > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > > > > >> On 2 Sep 2017, at 13:43, Fleshgrinder <php@fleshgrinder.com> 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. > > > > > > 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 positive) - > as long > > as they're ultimately represented on internals. > > > > > > My quick search suggested there was only roughly two days worth of > > discussion sometime in May, but it's possible I wasn't thorough in > searching. > > > > > > > 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. > > Richard, > > 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 > although at this point I don't think I did, that's still a possibility. > > My point is simple - when I saw the vote, I looked for the prior > discussion on internals - which is the *only* official channel for > discussing these 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 raised good points which remained unanswered, and it died out > very quickly without 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. > > > 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. > > That's great, but given that it's unprecedented, it's not a very good > argument. To quote Marco from the May discussion: > "Introducing a UUID class in PHP core as *just* a type safety wrapper > feels akin to adding an EmailAddress class to core. It's certainly not an > unreasonable way to handle things, but imho also not something that should > 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." > > > 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 > performance > > is a weak argument (which is debatable), it's most certainly not an > inherently > > weak argument as the current wording implies. There shouldn't be a > ratified > > PHP RFC implying that performance considerations are weak 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. > > There's a difference between certain people saying something, and 'most > people think'. There were only about 15 people that participated in this > 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. > > I could find some that said the opposite, including Ben Ramsey: > "A UUID generator in the core will only help to improve ramsey/uuid, > providing more choice and better performance." > The 'only' there might be confusing, but it's intended in a positive way. > > 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. > > > > Regardless of being final, they'll become a basic building block in > apps, and > > taking them away or modifying them means substantial breakage. The very > > introduction of the class, its name (and to a lesser degree its > functionality) - are > > tickets with remarkably expensive cancelation options. > > > > > > Zeev > > > > > > > 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. > > First, I do not prefer procedural programming. Personally I use OO a lot > 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 language. 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 across > the board, catering to the wide range of users in our community, and not > half baked according to the individual preferences of the subsets of 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 not > wanting to introduce a procedural API for creating a UUID. The > procedural/OO duality is not at all what people complain about when griping > about PHP's API mess. > Last, yes, the rationale is indeed true for most additions to the > language. The 2/3 barrier, as is explained in the Voting RFC ( > wiki.php.net/rfc/voting), has a rationale - the rationale being that > unlike changes in apps or frameworks, changes to the language have an > immense cost of reversal or incompatible alteration. Adding a top level > object that's four letters long falls squarely within that definition - > unlike, say, deciding when 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 the current UUID proposal is accepted as-is, would we > feel comfortable deprecating it with 50%+1 majority? If the answer's no, > introducing it shouldn't be at 50%+1 either. > > Zeev > > >
  100389
September 5, 2017 17:24 Fleshgrinder <php@fleshgrinder.com>
--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--
  100391
September 5, 2017 17:47 Fleshgrinder <php@fleshgrinder.com>
--5U8bLxSm46T12dCtwePN07IioFAovS7Ak
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

I'm sorry if my replies sound pissed. I'm generally not good at being
diplomatic in writing or talking, and currently under a lot of stress in
real life (which is of course not the problem of you guys).

Please bare with me, I honor all constructive feedback I receive, truly!

--=20
Richard "Fleshgrinder" Fussenegger


--5U8bLxSm46T12dCtwePN07IioFAovS7Ak--
  100399
September 5, 2017 23:00 me@sammyk.me (Sammy Kaye Powers)
> Richard wrote: > Maybe I should stop the vote. The discussion is happening now instead of > before when I asked for it.
I'm +1 for this because I'd love to see UUID's get added to PHP 7.3! :) Thanks, Sammy Kaye Powers sammyk.me
  100407
September 6, 2017 11:08 danack@basereality.com (Dan Ackroyd)
On 5 September 2017 at 18:24, Fleshgrinder <php@fleshgrinder.com> wrote:
> 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.
That would be fine and appropriate. The RFC targets 7.3. Having a discussion and vote in March gives plenty of time for getting it into 7.3 Cancelling a vote just to avoid an RFC being rejected is (imo) playing slightly fast and loose with the rules. cheers Dan Ack
  100410
September 6, 2017 11:42 arvids.godjuks@gmail.com (Arvids Godjuks)
I'd seriously start considering to start doing PHP code for things like
these, so they are not bogged down by the fact that they are in C and there
is 0.5 devs interested in supporting it.

On Wed, 6 Sep 2017, 14:09 Dan Ackroyd <danack@basereality.com> wrote:

> On 5 September 2017 at 18:24, Fleshgrinder <php@fleshgrinder.com> wrote: > > 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. > > That would be fine and appropriate. The RFC targets 7.3. Having a > discussion and vote in March gives plenty of time for getting it into > 7.3 > > Cancelling a vote just to avoid an RFC being rejected is (imo) playing > slightly fast and loose with the rules. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  100424
September 6, 2017 19:56 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> That would be fine and appropriate. The RFC targets 7.3. Having a > discussion and vote in March gives plenty of time for getting it into > 7.3 > > Cancelling a vote just to avoid an RFC being rejected is (imo) playing > slightly fast and loose with the rules.
I agree. I think the RFC itself is pretty clear. Some people agree with the way it goes, some do not. If the latter are in majority, we should let the vote finish, state the result as it is and then modify the RFC (if the author or anybody else wishes, of course) according to it to make it more acceptable, and then make another vote with the new proposal. At least to me, it looks like most people (me included) agree with the idea of having uuid implementation, but disagree with the specifics of the RFC. So a modified one could have better support, but there's no reason to not conclude the vote on the current one. BTW, the RFC text does not have vote end date, please add it. -- Stas Malyshev smalyshev@gmail.com
  100634
September 15, 2017 16:00 Fleshgrinder <php@fleshgrinder.com>
--9bKgs421M2ggBuc38nCVr6cbUhhUPWruV
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 9/6/2017 9:56 PM, Stanislav Malyshev wrote:
> BTW, the RFC text does not have vote end date, please add it. >=20
Done, had to move that to Wednesday, because I won't have Internet access until then. Closing it today would mean that the min of 2 weeks voting would not be achieved. --=20 Richard "Fleshgrinder" Fussenegger --9bKgs421M2ggBuc38nCVr6cbUhhUPWruV--
  100635
September 15, 2017 16:21 zeev@zend.com (Zeev Suraski)
Richard,

The minimal voting period is actually just one week, so as far as the Voting RFC requirements are concerned, you can close it right now.  If you want to stick to the Sep 16 deadline you announced at the beginning of the vote, someone else can close the poll, Sep 16 is just hours away.  Respectfully, it doesn't make sense to prolong it just because you don't have Internet access (plus, it's easy enough to work with wiki.php.net on 3G/mobile, from experience...)

Zeev


-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com] 
Sent: Friday, September 15, 2017 7:00 PM
To: Stanislav Malyshev <smalyshev@gmail.com>; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

On 9/6/2017 9:56 PM, Stanislav Malyshev wrote:
> BTW, the RFC text does not have vote end date, please add it. >
Done, had to move that to Wednesday, because I won't have Internet access until then. Closing it today would mean that the min of 2 weeks voting would not be achieved. -- Richard "Fleshgrinder" Fussenegger
  100636
September 15, 2017 16:31 me@kelunik.com (Niklas Keller)
> > Richard, > > The minimal voting period is actually just one week, so as far as the > Voting RFC requirements are concerned, you can close it right now. If you > want to stick to the Sep 16 deadline you announced at the beginning of the > vote, someone else can close the poll, Sep 16 is just hours away. > Respectfully, it doesn't make sense to prolong it just because you don't > have Internet access (plus, it's easy enough to work with wiki.php.net on > 3G/mobile, from experience...) > > Zeev >
If it's closed a few days later, it doesn't matter either. Regards, Niklas
  100356
September 3, 2017 17:02 andigutmans@gmail.com (Andi Gutmans)
Why would we not just add this under Spl? Feels like an appropriate place to put standard methods.
I would definitely not make functionality like this a top level class/namespace both for BC reasons and it is a minor capability that fits in well into 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 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).
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() 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.
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 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.
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 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.
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 something along the lines of uuid_v4_create() in a heartbeat. >
$bin = \UUID::v4()->toBinary(); $hex = \UUID::v4()->toHex(); $str = \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
  100358
September 3, 2017 22:27 cmbecker69@gmx.de ("Christoph M. Becker")
On 02.09.2017 at 09:01, Fleshgrinder wrote:

> 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).
IMHO, the RFC misses its own point. The introduction claims that uniqid() is insufficient, and that UUIDs are much more appropriate. I fully agree. However, instead of providing a single function to replace uniqid() it offers a full blown class which even includes *parsing* of UUIDs. The RFC furthermore claims: | A programming language’s standard module should provide the most basic | and repeating building blocks, to ensure that developers can achieve | things fast without much hassle. I fully agree, but I don't see that *parsing* of UUIDs is such a most basic building block, and even most of the rest of the proposed UUID class doesn't appear to fit that category. With regard to type-safety (which is probably the point of parse()): having type-safe UUIDs is only a fraction of one percent of what is occasionally needed in applications – do we really want to add thousands of classes to ext/standard? -- Christoph M. Becker
  100370
September 4, 2017 13:52 Remi Collet <remi@fedoraproject.org>
--iXVpXuFm5hQ66B5i6DnmoQ1G8wKAebtGR
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Le 02/09/2017 =C3=A0 09:01, Fleshgrinder a =C3=A9crit=C2=A0:
> Hello Internals! >=20 > 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. >=20 > The voting is open starting now and until September 16. (2 weeks). >=20
IMHO such a new thing should follow the common process to go to pecl first, and then merged in some new PHP version (like sodium) So -1 from me Remi --iXVpXuFm5hQ66B5i6DnmoQ1G8wKAebtGR--
  100371
September 4, 2017 16:03 me@sammyk.me (Sammy Kaye Powers)
I really, really wanted to vote yes for this as I've wanted simple
UUID creation in core for a long time, but I can't agree this is the
correct implementation. Something like "uuid_v4_create()" seems to
make a lot more pragmatic sense and use ramsey/uuid for anything more
complicated.

Sorry Richard, but I'm -1 on this one. But thanks for putting in all
the effort! I think another attempt with a simpler API &
implementation could be a winner! :)

Thanks,
Sammy Kaye Powers
sammyk.me


On Sat, Sep 2, 2017 at 2:01 AM, Fleshgrinder <php@fleshgrinder.com> wrote:
> 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 > >
  100377
September 5, 2017 07:32 arvids.godjuks@gmail.com (Arvids Godjuks)
2017-09-04 19:03 GMT+03:00 Sammy Kaye Powers <me@sammyk.me>:

> I really, really wanted to vote yes for this as I've wanted simple > UUID creation in core for a long time, but I can't agree this is the > correct implementation. Something like "uuid_v4_create()" seems to > make a lot more pragmatic sense and use ramsey/uuid for anything more > complicated. > > Sorry Richard, but I'm -1 on this one. But thanks for putting in all > the effort! I think another attempt with a simpler API & > implementation could be a winner! :) > > Thanks, > Sammy Kaye Powers > sammyk.me > > Hello everyone, it's been a while.
As a userland dev, I completely agree with the RFC. The implementation details may be worked out a bit, but having UUID's as an object is a good thing and having a proper reference implementation that follows the standard to the letter is very valuable. UUID's are a universal concept, used in so many systems across the IT world, that I personally consider them to be a thing on their own. I do believe they deserve to be an object - if you expect a UUID, you want a very specific thing, not just a generic string and then validate it every time with some form of "is_valid_uuid($uuid)". Even if PHP will have a reference implementation, 99.9% chance I will use a wrapper library that will give me an object I can work with. And not only for my personal preference, but also so other people working on the same project do not mess with a UUID string. Type hinting checks are also quite important, that I learned first hand lately as I went PHP 7.1 strict_types=1 on my whole codebase - I have been passing crap to in places that I would have never known, and probably would never result in an issue due to the nature of the error. I do, however, think that maybe doing a userland PHP implementation of the proposed module, so people can play and use it and then converting it to a PHP C module closer to 7.3 would be a better way. That way the API and features can be stabilized. -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  100381
September 5, 2017 11:36 php-lists@koalephant.com (Stephen Reay)
> On 5 Sep 2017, at 14:32, Arvids Godjuks godjuks@gmail.com> wrote: > > That way the API and > features can be stabilized.
(Sorry for resend, just realised I sent from a non-list email) Hi Arvids, This is exactly why I (and possibly others) are in favour of this being implemented as a few functions - the object side of things can then be left to a user land implementation, which is much easier to update and refine. Cheers Stephen
  100387
September 5, 2017 17:01 Andreas Heigl <andreas@heigl.org>
--MOV1H9I7oFwcWjbkTtGtqULgNsLKucGGx
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Am 02.09.17 um 09:01 schrieb Fleshgrinder:
> Hello Internals! >=20 > 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. >=20 > The voting is open starting now and until September 16. (2 weeks). >=20 Hey Richard, Hey all.
Thanks for putting up the RFC and the implementation! Having UUIDs in the core would be awesome. One of the reasons would be that it's in C. That'd be faster but would also allow easier integration with system-calls to be easier able to get the MAC-Address for a type-1 UUID f.e. But why limit UUIDs to type 3 through 5? Having security in mind is good IMHO but not implementing type 1 and 2 limits the usability and therefore the usefullness. Let the users decide whether they need it or not. As long as people can create SQL-Injections in PHP we should not use the security argument to limit usability or not implement standardized functionality. Especially when there is a full-fledged reference-implementation in userland available. In the RFC you reference ramsey/uuid yourself. But why should one use the internal UUID-class/functionality when there is a more powerful one in userland available? And limiting the usability and extendability of the UUID-Class itself by declaring it final means that userland-code can only wrap the class but not extend it. So userland code can not typehint for the UUID-class when special features are necessary that would need extending the class. And as there's no interface, I can't typehint for that either. So all in all for me that's * less functionality than the reference-implementation * missing UUID-types (the ones that are easier to implement in C) * missing extendability and a naging feeling that the imlementation decides what I as a user actually need. That's why I can't vote "yes". Sorry. Thanks for putting in the effort and coming up with a first implementatio= n. Cheers Andreas PS: Personally I don't like a "uuid_4_create" as that would also mean there should be a "uuid_1_create" through "uuid_5_create" as well and then there also would need to be a "uuid_1_verify" through "uuid_5_verify= "=E2=80=A6 --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --MOV1H9I7oFwcWjbkTtGtqULgNsLKucGGx--
  100390
September 5, 2017 17:29 Fleshgrinder <php@fleshgrinder.com>
--ed6QQxsC9tk6ua2IgN6dJ7JVL21SUn60D
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 9/5/2017 7:01 PM, Andreas Heigl wrote:
> Hey Richard, Hey all. >=20 > Thanks for putting up the RFC and the implementation! >=20 > Having UUIDs in the core would be awesome. One of the reasons would be > that it's in C. That'd be faster but would also allow easier integratio= n
> with system-calls to be easier able to get the MAC-Address for a type-1=
> UUID f.e. >=20 > But why limit UUIDs to type 3 through 5? Having security in mind is goo= d
> IMHO but not implementing type 1 and 2 limits the usability and > therefore the usefullness. Let the users decide whether they need it or=
> not. As long as people can create SQL-Injections in PHP we should not > use the security argument to limit usability or not implement > standardized functionality. >=20 > Especially when there is a full-fledged reference-implementation in > userland available. In the RFC you reference ramsey/uuid yourself. But > why should one use the internal UUID-class/functionality when there is = a
> more powerful one in userland available? >=20 > And limiting the usability and extendability of the UUID-Class itself b= y
> declaring it final means that userland-code can only wrap the class but=
> not extend it. So userland code can not typehint for the UUID-class whe= n
> special features are necessary that would need extending the class. And=
> as there's no interface, I can't typehint for that either. >=20 > So all in all for me that's >=20 > * less functionality than the reference-implementation > * missing UUID-types (the ones that are easier to implement in C) > * missing extendability >=20 > and a naging feeling that the imlementation decides what I as a user > actually need. >=20 > That's why I can't vote "yes". >=20 > Sorry. >=20 > Thanks for putting in the effort and coming up with a first implementat= ion.
>=20 > Cheers >=20 > Andreas >=20 > PS: Personally I don't like a "uuid_4_create" as that would also mean > there should be a "uuid_1_create" through "uuid_5_create" as well and > then there also would need to be a "uuid_1_verify" through "uuid_5_veri= fy"=E2=80=A6
>=20
Hi Andreas! Thanks for your feedback. We can easily add v1 and v2 because the class is final. It would not be a breaking change, or anything. v2 is pretty much useless imho, but v1 if done right would not even harm your privacy. Composition is more powerful than inheritance. You mention that you cannot extend it to add functionality, at the same time you want to type-hint against it. Well, in order to use the extended functionality you need to type-hint against your extended version. Hence, there is zero value for you in extending it other than having some place using the extended version, and others the core version without noticing that it got the extended version. The thing is, you should create your own value objects for your identifiers and hide the fact what it wraps. In C, and many other languages, we have type aliases. In PHP, and many other OO languages, we use composition to achieve that. Whether to make it final or not was discussed, and especially Ocramius agreed with me on this. I believe that it is the right choice. --=20 Richard "Fleshgrinder" Fussenegger --ed6QQxsC9tk6ua2IgN6dJ7JVL21SUn60D--
  100394
September 5, 2017 19:32 Andreas Heigl <andreas@heigl.org>
--aB9F09eXLVqqgrdxHmJWdBBQN2LhpxQBV
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hey Richard

Am 05.09.17 um 19:29 schrieb Fleshgrinder:
> On 9/5/2017 7:01 PM, Andreas Heigl wrote: >> Hey Richard, Hey all. >> >> Thanks for putting up the RFC and the implementation! >> >> Having UUIDs in the core would be awesome. One of the reasons would be=
>> that it's in C. That'd be faster but would also allow easier integrati= on
>> with system-calls to be easier able to get the MAC-Address for a type-= 1
>> UUID f.e. >> >> But why limit UUIDs to type 3 through 5? Having security in mind is go= od
>> IMHO but not implementing type 1 and 2 limits the usability and >> therefore the usefullness. Let the users decide whether they need it o= r
>> not. As long as people can create SQL-Injections in PHP we should not >> use the security argument to limit usability or not implement >> standardized functionality. >> >> Especially when there is a full-fledged reference-implementation in >> userland available. In the RFC you reference ramsey/uuid yourself. But=
>> why should one use the internal UUID-class/functionality when there is= a
>> more powerful one in userland available? >> >> And limiting the usability and extendability of the UUID-Class itself = by
>> declaring it final means that userland-code can only wrap the class bu= t
>> not extend it. So userland code can not typehint for the UUID-class wh= en
>> special features are necessary that would need extending the class. An= d
>> as there's no interface, I can't typehint for that either. >> >> So all in all for me that's >> >> * less functionality than the reference-implementation >> * missing UUID-types (the ones that are easier to implement in C) >> * missing extendability >> >> and a naging feeling that the imlementation decides what I as a user >> actually need. >> >> That's why I can't vote "yes". >> >> Sorry. >> >> Thanks for putting in the effort and coming up with a first implementa= tion.
>> >> Cheers >> >> Andreas >> >> PS: Personally I don't like a "uuid_4_create" as that would also mean >> there should be a "uuid_1_create" through "uuid_5_create" as well and >> then there also would need to be a "uuid_1_verify" through "uuid_5_ver= ify"=E2=80=A6
>> >=20 > Hi Andreas! >=20 > Thanks for your feedback. >=20 > We can easily add v1 and v2 because the class is final. It would not be=
> a breaking change, or anything. v2 is pretty much useless imho, but v1 > if done right would not even harm your privacy.
I'm with you there in so far that I personally don't see a value in a type 2 UUID. But there might be people that need exactly that. And as adding functionality usually isn't a BC-break that's OK.
>=20 > Composition is more powerful than inheritance. You mention that you > cannot extend it to add functionality, at the same time you want to > type-hint against it. Well, in order to use the extended functionality > you need to type-hint against your extended version. Hence, there is > zero value for you in extending it other than having some place using > the extended version, and others the core version without noticing that=
> it got the extended version.
I'm well aware of that and perhaps I didn't express myself as clear as I should have. Imagine a use-case where a UUID-class is needed. But alongside the toString, toHex and toBinary there's also the need for a further function (let's call it toArray). So currently I need to create a wrapper arround UUID that then needs to implement all the public methods of UUID as well as the new toArray. So it works identically to UUID but it isn't UUID. And I have no way of using my own UUID-Class - as it doesnt' extend UUID - as replacement for UUID. I'd need to expose the wrapped UUID-Class to be able to retrieve it whenever some libray expects a UUID. Perhaps this gist can make it clearer: https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa
>=20 > The thing is, you should create your own value objects for your > identifiers and hide the fact what it wraps. In C, and many other > languages, we have type aliases. In PHP, and many other OO languages, w= e
> use composition to achieve tha> > Whether to make it final or not was discussed, and especially Ocramius > agreed with me on this. I believe that it is the right choice.
I'm not saying it's the wrong choice. I for myself would probably not immediately use it as the ramsey/uuid-package is widely in use, but I could f.e. think, that that package might start to use the UUID-class under the hood. And then that would be a case where extending could be helpful as a \Ramsey\UUID would be an instance of \UUID. The alternative would be to implement a UUIDInterface that exposes the relevant methods and that would be implemented by \UUID itself. But that's just my 0.02=E2=82=AC Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --aB9F09eXLVqqgrdxHmJWdBBQN2LhpxQBV--
  100396
September 5, 2017 20:04 Fleshgrinder <php@fleshgrinder.com>
--mDhJhOegiHvWe0H53428AuW57HGDSqxU6
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 9/5/2017 9:32 PM, Andreas Heigl wrote:
> I'm well aware of that and perhaps I didn't express myself as clear as = I
> should have. >=20 > Imagine a use-case where a UUID-class is needed. But alongside the > toString, toHex and toBinary there's also the need for a further > function (let's call it toArray). So currently I need to create a > wrapper arround UUID that then needs to implement all the public method= s
> of UUID as well as the new toArray. So it works identically to UUID but=
> it isn't UUID. And I have no way of using my own UUID-Class - as it > doesnt' extend UUID - as replacement for UUID. I'd need to expose the > wrapped UUID-Class to be able to retrieve it whenever some libray > expects a UUID. Perhaps this gist can make it clearer: > https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa >=20 > I'm not saying it's the wrong choice. I for myself would probably not > immediately use it as the ramsey/uuid-package is widely in use, but I > could f.e. think, that that package might start to use the UUID-class > under the hood. And then that would be a case where extending could be > helpful as a \Ramsey\UUID would be an instance of \UUID. >=20 > The alternative would be to implement a UUIDInterface that exposes the > relevant methods and that would be implemented by \UUID itself. >=20 > But that's just my 0.02=E2=82=AC >=20 > Cheers >=20 > Andreas >=20
OK, now I understand it better. I would argue that if we really find something existential that should be added, we should add it to the UUID class itself. See, the problem with allowing extension is that we have a real BC issue. All your arguments are well received and correct, but the open a can of worms that is impossible to close. Keeping it final ensures that this cannot happen, ever. We can continue to refine without breaking anyone. I think it also was Ocramius who released a nice article about "final first", but there are probably many from the Java world. Btw. the interface does not really make sense. Interfaces are for polymorphism, in other words, if there are different implementations of the same thing that should be usable interchangeably. This is definitely not the case with UUIDs, the algorithm is set in stone. Don't forget that you can instantiate any kind of UUID with the `fromBinary` method, so you can easily generate different UUIDs on your own and still use the built-in class; no need for extension. --=20 Richard "Fleshgrinder" Fussenegger --mDhJhOegiHvWe0H53428AuW57HGDSqxU6--
  100402
September 6, 2017 07:19 me@kelunik.com (Niklas Keller)
On Di., 5. Sep. 2017, 21:32 Andreas Heigl <andreas@heigl.org> wrote:

> Hey Richard > > Am 05.09.17 um 19:29 schrieb Fleshgrinder: > > On 9/5/2017 7:01 PM, Andreas Heigl wrote: > >> Hey Richard, Hey all. > >> > >> Thanks for putting up the RFC and the implementation! > >> > >> Having UUIDs in the core would be awesome. One of the reasons would be > >> that it's in C. That'd be faster but would also allow easier integration > >> with system-calls to be easier able to get the MAC-Address for a type-1 > >> UUID f.e. > >> > >> But why limit UUIDs to type 3 through 5? Having security in mind is good > >> IMHO but not implementing type 1 and 2 limits the usability and > >> therefore the usefullness. Let the users decide whether they need it or > >> not. As long as people can create SQL-Injections in PHP we should not > >> use the security argument to limit usability or not implement > >> standardized functionality. > >> > >> Especially when there is a full-fledged reference-implementation in > >> userland available. In the RFC you reference ramsey/uuid yourself. But > >> why should one use the internal UUID-class/functionality when there is a > >> more powerful one in userland available? > >> > >> And limiting the usability and extendability of the UUID-Class itself by > >> declaring it final means that userland-code can only wrap the class but > >> not extend it. So userland code can not typehint for the UUID-class when > >> special features are necessary that would need extending the class. And > >> as there's no interface, I can't typehint for that either. > >> > >> So all in all for me that's > >> > >> * less functionality than the reference-implementation > >> * missing UUID-types (the ones that are easier to implement in C) > >> * missing extendability > >> > >> and a naging feeling that the imlementation decides what I as a user > >> actually need. > >> > >> That's why I can't vote "yes". > >> > >> Sorry. > >> > >> Thanks for putting in the effort and coming up with a first > implementation. > >> > >> Cheers > >> > >> Andreas > >> > >> PS: Personally I don't like a "uuid_4_create" as that would also mean > >> there should be a "uuid_1_create" through "uuid_5_create" as well and > >> then there also would need to be a "uuid_1_verify" through > "uuid_5_verify"… > >> > > > > Hi Andreas! > > > > Thanks for your feedback. > > > > We can easily add v1 and v2 because the class is final. It would not be > > a breaking change, or anything. v2 is pretty much useless imho, but v1 > > if done right would not even harm your privacy. > > I'm with you there in so far that I personally don't see a value in a > type 2 UUID. But there might be people that need exactly that. And as > adding functionality usually isn't a BC-break that's OK. > > > > > Composition is more powerful than inheritance. You mention that you > > cannot extend it to add functionality, at the same time you want to > > type-hint against it. Well, in order to use the extended functionality > > you need to type-hint against your extended version. Hence, there is > > zero value for you in extending it other than having some place using > > the extended version, and others the core version without noticing that > > it got the extended version. > > I'm well aware of that and perhaps I didn't express myself as clear as I > should have. > > Imagine a use-case where a UUID-class is needed. But alongside the > toString, toHex and toBinary there's also the need for a further > function (let's call it toArray). So currently I need to create a > wrapper arround UUID that then needs to implement all the public methods > of UUID as well as the new toArray. So it works identically to UUID but > it isn't UUID. And I have no way of using my own UUID-Class - as it > doesnt' extend UUID - as replacement for UUID. I'd need to expose the > wrapped UUID-Class to be able to retrieve it whenever some libray > expects a UUID. Perhaps this gist can make it clearer: > https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa
How about a simple function that takes an UUID and returns what you want? People often forget that they exist in PHP. Regards, Niklas
> > > > The thing is, you should create your own value objects for your > > identifiers and hide the fact what it wraps. In C, and many other > > languages, we have type aliases. In PHP, and many other OO languages, we > > use composition to achieve tha> > > Whether to make it final or not was discussed, and especially Ocramius > > agreed with me on this. I believe that it is the right choice. > > I'm not saying it's the wrong choice. I for myself would probably not > immediately use it as the ramsey/uuid-package is widely in use, but I > could f.e. think, that that package might start to use the UUID-class > under the hood. And then that would be a case where extending could be > helpful as a \Ramsey\UUID would be an instance of \UUID. > > The alternative would be to implement a UUIDInterface that exposes the > relevant methods and that would be implemented by \UUID itself. > > But that's just my 0.02€ > > Cheers > > Andreas > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | > | http://andreas.heigl.org http://hei.gl/wiFKy7 | > +---------------------------------------------------------------------+ > | http://hei.gl/root-ca | > +---------------------------------------------------------------------+ > >