This is only part of a thread. view whole thread
September 5, 2017 07:32 (Arvids Godjuks)
2017-09-04 19:03 GMT+03:00 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 > > > 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 Skype: psihius Telegram: @psihius
September 5, 2017 11:36 (Stephen Reay)
> On 5 Sep 2017, at 14:32, Arvids Godjuks> 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