Re: [VOTE] UUID
| From: | Arvids Godjuks | 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