Re: [PHP-DEV] [VOTE] UUID

This is only part of a thread. view whole thread
  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