> On 5 Sep 2017, at 14:32, Arvids Godjuks email@example.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.
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.
+371 26 851 664
Telegram: @psihius https://t.me/psihius