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 <firstname.lastname@example.org> 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 > >September 5, 2017 07:32 email@example.com (Arvids Godjuks)2017-09-04 19:03 GMT+03:00 Sammy Kaye Powers <firstname.lastname@example.org>:> 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 email@example.com Skype: psihius Telegram: @psihius https://t.me/psihiusSeptember 5, 2017 11:36 firstname.lastname@example.org (Stephen Reay)> On 5 Sep 2017, at 14:32, Arvids Godjuks(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
email@example.com> wrote: > > That way the API and > features can be stabilized.