Re: [VOTE] UUID

From: Date: Tue, 05 Sep 2017 09:54:09 +0000
Subject: Re: [VOTE] UUID
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-100378@lists.php.net to get a copy of this message
2017-09-05 12:24 GMT+03:00 Stephen Reay <stephen@bobs-bits.com>: > > On 5 Sep 2017, at 14:32, Arvids Godjuks <arvids.godjuks@gmail.com> wrote: > > That way the API and > features can be stabilized. > > > 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 > > I would agree if this was something that was in flux or didn't have a set in stone standard that is universal across languages, platforms and all kinds of other software (databases come to mind, some have full-blown first-class citizen support for them, MySQL is also on the path to introducing them as field type last I heard too). This is about making a UUID a first-class citizen and having it universally available going forward, be able to use it as a type hint, same as DateTimeInterface is used these days (a lot, actually). Just provide a procedural-style API together with the OOP one. I recon the OOP one is gonna be used way more though - every userland implementation I ever saw used an OOP approach. Or just start packaging PHP code that is shipped with the interpreter: Ship the Ramsey\Uuid with 7.3 or some 7.2.x release. That one seems the defacto standard everyone uses, and it is used in my current project too :) Would be a perfect segway for the discussion we had on the list a few months ago about doing parts of the packaged modules in PHP itself. -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

« previous php.internals (#100378) next »