Re: [PHP-DEV] [VOTE] UUID

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