On 9/4/2017 11:04 AM, Zeev Suraski wrote:
> 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.
>
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 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.
>
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 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."
>
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 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.
>
That was probably on some other channel. As I said, I'm more than happy
to change that wording. =)
On 9/4/2017 11:04 AM, Zeev Suraski wrote:
> 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
>
>
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 own?
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,
... 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.
--
Richard "Fleshgrinder" Fussenegger
