Re: [PHP-DEV] [VOTE] UUID

This is only part of a thread. view whole thread
  100371
September 4, 2017 16:03 me@sammyk.me (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
sammyk.me


On Sat, Sep 2, 2017 at 2:01 AM, Fleshgrinder <php@fleshgrinder.com> 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 > >
  100377
September 5, 2017 07:32 arvids.godjuks@gmail.com (Arvids Godjuks)
2017-09-04 19:03 GMT+03:00 Sammy Kaye Powers <me@sammyk.me>:

> 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 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
  100381
September 5, 2017 11:36 php-lists@koalephant.com (Stephen Reay)
> On 5 Sep 2017, at 14:32, Arvids Godjuks godjuks@gmail.com> 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