Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] [Discussion] UUID

Posted by Fleshgrinder 
Fleshgrinder
[PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 02:40AM
Hey internals!

I haven't written the RFC yet, but the implementation is already done. I
think that this is enough to start the discussion, since the concept of
UUIDs should be well known to most people.

https://github.com/php/php-src/pull/2535

The best starting point, also for non-C people, is the stubs directory
where I created PHP files with full documentation:

https://github.com/Fleshgrinder/php-src/tree/rfc/uuid/ext/standard/stubs

I am also planning on providing PHP 5 and 7 polyfills, so that people
can prepare their code long before the feature is actually landing in
userland.

--
Richard "Fleshgrinder" Fussenegger
Dan Ackroyd
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 11:30AM
> Hey internals!
>
> I haven't written the RFC yet,

Please don't forget to include in the RFC a justification for why this
should be part of PHP core, rather than a library.

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:
>> Hey internals!
>>
>> I haven't written the RFC yet,
>
> Please don't forget to include in the RFC a justification for why this
> should be part of PHP core, rather than a library

because as developer in reality you can not use and rely on features
which needs to install some pecl-library when it is supposed to be used
on typical hosting packages

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 05:10PM
On 05/24/2017 04:31 AM, lists@rhsoft.net wrote:
>
>
> Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:
>>> Hey internals!
>>>
>>> I haven't written the RFC yet,
>>
>> Please don't forget to include in the RFC a justification for why this
>> should be part of PHP core, rather than a library
>
> because as developer in reality you can not use and rely on features
> which needs to install some pecl-library when it is supposed to be
> used on typical hosting packages

It doesn't have to be a PECL library. I agree that a project requiring
a PECL library greatly limits its potential reach, but with Composer
user-space libraries are totally easy to install. There's a nice and
popular UUID implementation already:

https://packagist.org/packages/ramsey/uuid

Note: That doesn't mean adding UUID functionality to PHP core/standard
lib is a bad idea; discussing that is fine. But the "no one will be
able to use it otherwise" argument is substantially less compelling than
it was even 5 years ago.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 05:20PM
On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <[email protected]>
wrote:

> On 05/24/2017 04:31 AM, lists@rhsoft.net wrote:
>
>>
>>
>> Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:
>>
>>> Hey internals!
>>>>
>>>> I haven't written the RFC yet,
>>>>
>>>
>>> Please don't forget to include in the RFC a justification for why this
>>> should be part of PHP core, rather than a library
>>>
>>
>> because as developer in reality you can not use and rely on features
>> which needs to install some pecl-library when it is supposed to be used on
>> typical hosting packages
>>
>
> It doesn't have to be a PECL library. I agree that a project requiring a
> PECL library greatly limits its potential reach, but with Composer
> user-space libraries are totally easy to install. There's a nice and
> popular UUID implementation already:
>
> https://packagist.org/packages/ramsey/uuid
>
> Note: That doesn't mean adding UUID functionality to PHP core/standard lib
> is a bad idea; discussing that is fine. But the "no one will be able to
> use it otherwise" argument is substantially less compelling than it was
> even 5 years ago.
>
> --Larry Garfield


By the way there already is a PECL package for a UUID library:
https://pecl.php.net/package/uuid. I would like to see compelling reasons
why we shouldn't rally around that package.
Am 24.05.2017 um 17:04 schrieb Larry Garfield:
> On 05/24/2017 04:31 AM, lists@rhsoft.net wrote:
>>
>> Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:
>>>> Hey internals!
>>>>
>>>> I haven't written the RFC yet,
>>>
>>> Please don't forget to include in the RFC a justification for why this
>>> should be part of PHP core, rather than a library
>>
>> because as developer in reality you can not use and rely on features
>> which needs to install some pecl-library when it is supposed to be
>> used on typical hosting packages
>
> It doesn't have to be a PECL library. I agree that a project requiring
> a PECL library greatly limits its potential reach, but with Composer
> user-space libraries are totally easy to install. There's a nice and
> popular UUID implementation already

frankly get out of my sight with composer

i maintain the whole webstacke for many years at my own (rpm packages)
and so the Fedora repos have excluded anything relevant to PHP - trying
to build composer by just download the src.rpm ends in a ton of build
dependencies, bootsrap stuff because of cyclic dependencies, frameworks
nobody needs and wants in environments where 3rd party code is
discouraged because it becomes a problem sooner or later in case of
upgrades and so composer is just a red flag for me until a PHP build
spits out a /usr/bin/composer binary which is self contained

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 24.05.2017 um 17:11 schrieb Levi Morrison:
> On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <[email protected]>
> wrote:
>
>> On 05/24/2017 04:31 AM, lists@rhsoft.net wrote:
>>>
>>> Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:
>>>
>>>> Hey internals!
>>>>>
>>>>> I haven't written the RFC yet,
>>>>
>>>> Please don't forget to include in the RFC a justification for why this
>>>> should be part of PHP core, rather than a library
>>>
>>> because as developer in reality you can not use and rely on features
>>> which needs to install some pecl-library when it is supposed to be used on
>>> typical hosting packages
>>
>> It doesn't have to be a PECL library. I agree that a project requiring a
>> PECL library greatly limits its potential reach, but with Composer
>> user-space libraries are totally easy to install. There's a nice and
>> popular UUID implementation already:
>>
>> https://packagist.org/packages/ramsey/uuid
>>
>> Note: That doesn't mean adding UUID functionality to PHP core/standard lib
>> is a bad idea; discussing that is fine. But the "no one will be able to
>> use it otherwise" argument is substantially less compelling than it was
>> even 5 years ago.
>>
> By the way there already is a PECL package for a UUID library:
> https://pecl.php.net/package/uuid. I would like to see compelling reasons
> why we shouldn't rally around that package
because when you end in a library/extension for each and every trivial
function your codebase becomes a mess - why not PECL i have explained
before the post you quoted and why composer as it is working nwo is a
no-go in the follow-up response

not that i care much of *that* function but when in the future every
functionality ends in pecl and/or composer, well, my list what not to
touch will grow in the same speed

we maintain a large codebase (250000 LOC) over 15 years and the only 3rd
party library is 'phpmailer' and besides php-pecl-apcu and
php-pecl-imagick on prodcution machines there are no 3rd partly librarie
and won't be that soon - not interested in the mess 10 years later while
currently i can deploy hundrets of instances with a self-contained
deployment software using the same framework as the application and it's
modules and build/test a php-build whithn a few minutes be it 7.0.x,
7.1.x, 7.2.x

with every single external dependency that becomes harder

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 06:00PM
On Wed, May 24, 2017 at 9:29 AM, lists@rhsoft.net <[email protected]> wrote:

>
>
> Am 24.05.2017 um 17:11 schrieb Levi Morrison:
>
>> On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <[email protected]>
>> wrote:
>>
>> On 05/24/2017 04:31 AM, lists@rhsoft.net wrote:
>>>
>>>>
>>>> Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:
>>>>
>>>> Hey internals!
>>>>>
>>>>>>
>>>>>> I haven't written the RFC yet,
>>>>>>
>>>>>
>>>>> Please don't forget to include in the RFC a justification for why this
>>>>> should be part of PHP core, rather than a library
>>>>>
>>>>
>>>> because as developer in reality you can not use and rely on features
>>>> which needs to install some pecl-library when it is supposed to be used
>>>> on
>>>> typical hosting packages
>>>>
>>>
>>> It doesn't have to be a PECL library. I agree that a project requiring a
>>> PECL library greatly limits its potential reach, but with Composer
>>> user-space libraries are totally easy to install. There's a nice and
>>> popular UUID implementation already:
>>>
>>> https://packagist.org/packages/ramsey/uuid
>>>
>>> Note: That doesn't mean adding UUID functionality to PHP core/standard
>>> lib
>>> is a bad idea; discussing that is fine. But the "no one will be able to
>>> use it otherwise" argument is substantially less compelling than it was
>>> even 5 years ago.
>>>
>>> By the way there already is a PECL package for a UUID library:
>> https://pecl.php.net/package/uuid. I would like to see compelling reasons
>> why we shouldn't rally around that package
>>
> because when you end in a library/extension for each and every trivial
> function your codebase becomes a mess - why not PECL i have explained
> before the post you quoted and why composer as it is working nwo is a no-go
> in the follow-up response
>

You misunderstood my message. Why would we write a new UUID package written
in C when there is already a UUID package in PECL? Why is the existing UUID
package in PECL is insufficient?

I understand the user experience improvement for having a package for UUIDs
in core; I'd like that myself. I just want to know why we haven't discussed
the existing UUID package and made a new one.
Remi Collet
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 06:30PM
Le 24/05/2017 à 17:57, Levi Morrison a écrit :

> I understand the user experience improvement for having a package for UUIDs
> in core; I'd like that myself. I just want to know why we haven't discussed
> the existing UUID package and made a new one.

I agree here, why a new extension ?

And I also think using system libuuid is better than reinventing the
wheel, and having to maintain a uuid algo, when already maintained by
someone else, which only work on these algo.


Remi.
Remi Collet
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 06:40PM
Le 24/05/2017 à 17:21, lists@rhsoft.net a écrit :

> frankly get out of my sight with composer
>
> i maintain the whole webstacke for many years at my own (rpm packages)
> and so the Fedora repos have excluded anything relevant to PHP - trying
> to build composer by just download the src.rpm ends in a ton of build
> dependencies, bootsrap stuff because of cyclic dependencies, frameworks
> nobody needs and wants in environments where 3rd party code is
> discouraged because it becomes a problem sooner or later in case of
> upgrades and so composer is just a red flag for me until a PHP build
> spits out a /usr/bin/composer binary which is self contained
>

I definitively don't understand your point.

If you want composer, you will ALWAYS need Symfony (and some other
pieces). Composer is symfony app.

And, the boostrap process is only about enabling/disabling test suite.

And IMHO having test suite in all packages is a very important part of
QA, with benefit for Fedora (ensure consistency) but also for upstream
projects.



Remi.


P.S. and probably out of topic here, if you want to improve fedora
packaging Guidelines, simply join the php-devel@fedoraproject.org
mailing list.
Christoph M. Becker
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 06:40PM
On 24.05.2017 at 18:25, Remi Collet wrote:

> Le 24/05/2017 à 17:57, Levi Morrison a écrit :
>
>> I understand the user experience improvement for having a package for UUIDs
>> in core; I'd like that myself. I just want to know why we haven't discussed
>> the existing UUID package and made a new one.
>
> I agree here, why a new extension ?
>
> And I also think using system libuuid is better than reinventing the
> wheel, and having to maintain a uuid algo, when already maintained by
> someone else, which only work on these algo.

What about Windows support?

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 24.05.2017 um 18:30 schrieb Remi Collet:
> Le 24/05/2017 à 17:21, lists@rhsoft.net a écrit :
>
>> frankly get out of my sight with composer
>>
>> i maintain the whole webstacke for many years at my own (rpm packages)
>> and so the Fedora repos have excluded anything relevant to PHP - trying
>> to build composer by just download the src.rpm ends in a ton of build
>> dependencies, bootsrap stuff because of cyclic dependencies, frameworks
>> nobody needs and wants in environments where 3rd party code is
>> discouraged because it becomes a problem sooner or later in case of
>> upgrades and so composer is just a red flag for me until a PHP build
>> spits out a /usr/bin/composer binary which is self contained
>>
>
> I definitively don't understand your point.

why?

> If you want composer, you will ALWAYS need Symfony (and some other
> pieces). Composer is symfony app.

and here the problem starts

i DO NOT want Symfony because i don't have a need for any 3rd party
software just because i don't have "fire and forget" projects - i have
*one* project for a lifetime which covers all

* frameworks
* abstraction layers
* on top a CMS
* on top of the CMS customer sites
* on top of the CMS admin backaneds for dns/epp/httpd/mail...
* and since the framework as well as the CMS support CLI mode
a ton of automation for maintain services, cms-tasks, cleanups
and all needed admin staff for the whole infrastructure

from the moment on a introdcue 3rd party frameworks i am no longer free
to build PHP as i like it and the version i want

stripped down to a minimum and only enable and compile needed
extensions, package everything as loadable extensions and manage the
whole stuff with rpm-meta-packages

the only acceptable things here are PHAR files like phpdoc

[[email protected]:~]$ php -n -m
[PHP Modules]
Core
date
filter
libxml
pcre
Reflection
SPL
standard

and frankly i would love to anyhting above and *especially* standard as
loadable extensions instead have it in /usr/bin/php *and*
/usr/lib64/httpd/modules/libphp7.so compiled beause, well, we run also
native system services written in PHP which could have a smaller footprint

if ou need some ideas for teh Fedora "rpm.spec" take a look at the
attachment :-)



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 24.05.2017 um 18:35 schrieb Christoph M. Becker:
> On 24.05.2017 at 18:25, Remi Collet wrote:
>
>> Le 24/05/2017 à 17:57, Levi Morrison a écrit :
>>
>>> I understand the user experience improvement for having a package for UUIDs
>>> in core; I'd like that myself. I just want to know why we haven't discussed
>>> the existing UUID package and made a new one.
>>
>> I agree here, why a new extension ?
>>
>> And I also think using system libuuid is better than reinventing the
>> wheel, and having to maintain a uuid algo, when already maintained by
>> someone else, which only work on these algo.
>
> What about Windows support?

in times of virtualization and containers i personally would go so far
and question the need for support windows native at all which would lead
to a much smaller and cleaner codebase and less maintainance overhead

(not only for PHP)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 08:10PM
On 5/24/2017 5:11 PM, Levi Morrison wrote:
> On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <[email protected]>
> wrote:
>
>> It doesn't have to be a PECL library. I agree that a project requiring a
>> PECL library greatly limits its potential reach, but with Composer
>> user-space libraries are totally easy to install. There's a nice and
>> popular UUID implementation already:
>>
>> https://packagist.org/packages/ramsey/uuid
>>
>> Note: That doesn't mean adding UUID functionality to PHP core/standard lib
>> is a bad idea; discussing that is fine. But the "no one will be able to
>> use it otherwise" argument is substantially less compelling than it was
>> even 5 years ago.
>>
>> --Larry Garfield
>
>
> By the way there already is a PECL package for a UUID library:
> https://pecl.php.net/package/uuid. I would like to see compelling reasons
> why we shouldn't rally around that package.
>

What is wrong with `ramsey/uuid`?

Well, absolutely nothing. I personally would consider it
over-engineered, but that is no real reason. My implementation is after
all not an attack on a well maintained Composer package. The fact that
this package was downloaded almost 10 million times however is an
indicator that that functionality is required a lot. What is an STD for?
Exactly, to provide things that are needed everywhere. This is exactly
the reason why I want to see UUIDs as part of PHP's STD.

What is wrong with PECL's uuid?

Of course I know about that package. The problems I have with it are simple:

- It just exposes a C API to userland, without considering that PHP is
becoming less and less procedural.
- It is not type-safe:
- its own functions aren't, and
- its generated values aren't.
- It works around existing PHP implementations by adding a new
dependency that is Linux only:
- no Windows
- no BSD

The implementation I am providing is extremely simple, and makes use of
existing PHP functionality:

- It works on any operating system that PHP supports.
- A change to `random_bytes` directly upgrades my UUID implementation.
- The same is true for MD5 and SHA1 (unlikely, but hey).
- It has zero outside dependencies.
- It is extremely type-safe.
- It has a well though through object-oriented API.
- It supports serialization out-of-the-box without extra effort because
I use, once again, the built-in PHP stuff.
- It supports comparison out-of-the-box without extra effort because I
use, once again, the built-in PHP stuff (no overloading!).

Of course, you guys can disagree with all of these. However, the
implementation is extremely trivial. Almost everything is just PHP API
code. The only thing that has actual real logic is the `parse` method,
but that code is trivial too (just have a look at it).

--
Richard "Fleshgrinder" Fussenegger
Marco Pivetta
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 08:20PM
On Wed, May 24, 2017 at 8:01 PM, Fleshgrinder <[email protected]> wrote:

> On 5/24/2017 5:11 PM, Levi Morrison wrote:
> > On Wed, May 24, 2017 at 9:04 AM, Larry Garfield <[email protected]>
> > wrote:
> >
> >> It doesn't have to be a PECL library. I agree that a project requiring
> a
> >> PECL library greatly limits its potential reach, but with Composer
> >> user-space libraries are totally easy to install. There's a nice and
> >> popular UUID implementation already:
> >>
> >> https://packagist.org/packages/ramsey/uuid
> >>
> >> Note: That doesn't mean adding UUID functionality to PHP core/standard
> lib
> >> is a bad idea; discussing that is fine. But the "no one will be able to
> >> use it otherwise" argument is substantially less compelling than it was
> >> even 5 years ago.
> >>
> >> --Larry Garfield
> >
> >
> > By the way there already is a PECL package for a UUID library:
> > https://pecl.php.net/package/uuid. I would like to see compelling
> reasons
> > why we shouldn't rally around that package.
> >
>
> What is wrong with `ramsey/uuid`?
>
> Well, absolutely nothing. I personally would consider it
> over-engineered, but that is no real reason. My implementation is after
> all not an attack on a well maintained Composer package. The fact that
> this package was downloaded almost 10 million times however is an
> indicator that that functionality is required a lot. What is an STD for?
> Exactly, to provide things that are needed everywhere. This is exactly
> the reason why I want to see UUIDs as part of PHP's STD.
>

Indeed: UUIDs are much, much, much needed feature.


> What is wrong with PECL's uuid?
>
> Of course I know about that package. The problems I have with it are
> simple:
>
> - It just exposes a C API to userland, without considering that PHP is
> becoming less and less procedural.
>

For once, I must say that I disagree with having an OOP API defined in core.
This can exist in userland, so it probably should. Internal classes, their
reflection, behavior, inheritance model, etc are full of quirks.
There's nothing wrong in returning a string, then having a userland lib
make it into a UUID value object: it actually is better for everyone's
sanity.
It would (probably) be better to stop at the function that actually
generates the identifier, then having the boxed value defined in userland
anyway. Yes, we lose the type hinting, but damn are internal classes ugly.
If you must keep the object style, make it `final`, so at least we won't
have people extending this thing for no good reason at all :-P

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Jan Ehrhardt
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 08:20PM
"Christoph M. Becker" in php.internals (Wed, 24 May 2017 18:35:08
+0200):
>On 24.05.2017 at 18:25, Remi Collet wrote:
>
>> And I also think using system libuuid is better than reinventing the
>> wheel, and having to maintain a uuid algo, when already maintained by
>> someone else, which only work on these algo.
>
>What about Windows support?

UuidCreate:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379205(v=vs.85).aspx
The Apache Portable Library (APR) uses it for a long, long time:
http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/rand.c?view=markup#l65
--
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 08:50PM
On 5/24/2017 8:09 PM, Marco Pivetta wrote:
> For once, I must say that I disagree with having an OOP API defined in core.
> This can exist in userland, so it probably should. Internal classes, their
> reflection, behavior, inheritance model, etc are full of quirks.
> There's nothing wrong in returning a string, then having a userland lib
> make it into a UUID value object: it actually is better for everyone's
> sanity.
> It would (probably) be better to stop at the function that actually
> generates the identifier, then having the boxed value defined in userland
> anyway. Yes, we lose the type hinting, but damn are internal classes ugly.
> If you must keep the object style, make it `final`, so at least we won't
> have people extending this thing for no good reason at all :-P
>
> Marco Pivetta
>

The problem with procedural APIs is, especially with the way the PECL
UUID is implemented, that you are constantly converting back and forth.
While OO allows you to encapsulate your things.

There is actually only a single thing that is not (yet) possible with
Reflection on internal methods: getting the default values of a
parameter. I wrote Reflection tests for every single thing, to ensure
that it works as good as possible. Have a look at the `definition.phpt`
test cases:

https://github.com/Fleshgrinder/php-src/tree/rfc/uuid/ext/standard/tests/uuid

Here is one where I had do comment the default value thingy:

https://github.com/Fleshgrinder/php-src/blob/rfc/uuid/ext/standard/tests/uuid/UUIDParseException/__construct/definition-005.phpt#L15

And yes, everything is `final` to ensure that nobody can do anything
with the classes. This applies to the `UUID` and the `UUIDParseException`.

Furthermore, I carefully crafted everything to be as close to userland
as possible. No magic, none at all. I use default PHP built-in stuff for
everything. Even the parameter parsing is 1:1 as it would be if you
would define the very same class in PHP.

I will extend my signature with "No Magic!" now. ;)

--
Richard "Fleshgrinder" Fussenegger
Marco Pivetta
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 08:50PM
On Wed, May 24, 2017 at 8:39 PM, Fleshgrinder <[email protected]> wrote:

> On 5/24/2017 8:09 PM, Marco Pivetta wrote:
> > For once, I must say that I disagree with having an OOP API defined in
> core.
> > This can exist in userland, so it probably should. Internal classes,
> their
> > reflection, behavior, inheritance model, etc are full of quirks.
> > There's nothing wrong in returning a string, then having a userland lib
> > make it into a UUID value object: it actually is better for everyone's
> > sanity.
> > It would (probably) be better to stop at the function that actually
> > generates the identifier, then having the boxed value defined in userland
> > anyway. Yes, we lose the type hinting, but damn are internal classes
> ugly.
> > If you must keep the object style, make it `final`, so at least we won't
> > have people extending this thing for no good reason at all :-P
> >
> > Marco Pivetta
> >
>
> The problem with procedural APIs is, especially with the way the PECL
> UUID is implemented, that you are constantly converting back and forth.
> While OO allows you to encapsulate your things.
>

Yup, converting is indeed problematic.


> There is actually only a single thing that is not (yet) possible with
> Reflection on internal methods: getting the default values of a
> parameter. I wrote Reflection tests for every single thing, to ensure
> that it works as good as possible. Have a look at the `definition.phpt`
> test cases:
>
> https://github.com/Fleshgrinder/php-src/tree/rfc/
> uuid/ext/standard/tests/uuid


That's actually awesome! Well done, this pretty much nullifies my fears


> Here is one where I had do comment the default value thingy:
>
> https://github.com/Fleshgrinder/php-src/blob/rfc/
> uuid/ext/standard/tests/uuid/UUIDParseException/__
> construct/definition-005.phpt#L15


Ok, this is inherited API that is broken in all libraries anyway due to
default value reflection, so I guess it's good to go.


>
>
> And yes, everything is `final` to ensure that nobody can do anything
> with the classes. This applies to the `UUID` and the `UUIDParseException`.
>

Thanks!


>
> Furthermore, I carefully crafted everything to be as close to userland
> as possible. No magic, none at all. I use default PHP built-in stuff for
> everything. Even the parameter parsing is 1:1 as it would be if you
> would define the very same class in PHP.
>
> I will extend my signature with "No Magic!" now. ;)
>

Perfect, this absolutely makes it a huge :+1: on my side.

Last thing I'd suggest is to grab Ben Ramsey and get him to check the patch
:-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Ben Ramsey
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 24, 2017 10:20PM
On Wed, May 24, 2017 at 2:47 PM, Marco Pivetta <[email protected]> wrote:
>
> On Wed, May 24, 2017 at 8:39 PM, Fleshgrinder <[email protected]> wrote:
> >
> > Furthermore, I carefully crafted everything to be as close to userland
> > as possible. No magic, none at all. I use default PHP built-in stuff for
> > everything. Even the parameter parsing is 1:1 as it would be if you
> > would define the very same class in PHP.
> >
> > I will extend my signature with "No Magic!" now. ;)
> >
>
> Perfect, this absolutely makes it a huge :+1: on my side.
>
> Last thing I'd suggest is to grab Ben Ramsey and get him to check the patch
> :-)
>

I'll take a look at the patch soon. If this is accepted to the core,
I'll probably add an adapter to ramsey/uuid that wraps this
implementation. The point of the "over engineering" there is to provide
choice. Some users want to generate bytes from sources other than
random_bytes() (i.e., libsodium) or encode UUIDs in different ways
(i.e., ordered time). A UUID generator in the core will only help to
improve ramsey/uuid, providing more choice and better performance.

I may split out the less-used adapters and codecs into separate
components in version 4 or 5 of ramsey/uuid, though, since most users
don't need anything other than the default.

-Ben

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 01:10AM
On Wed, May 24, 2017 at 11:04 AM, Larry Garfield <[email protected]> wrote:
> It doesn't have to be a PECL library. I agree that a project requiring a
> PECL library greatly limits its potential reach, but with Composer
> user-space libraries are totally easy to install. There's a nice and popular
> UUID implementation already:
>
> https://packagist.org/packages/ramsey/uuid
>
This, and entirely this.

There's no justification for doing this in C anymore, we have a high
level language for tasks like this. It's called PHP.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 12:10PM
On 5/24/2017 10:12 PM, Ben Ramsey wrote:
> I'll take a look at the patch soon. If this is accepted to the core,
> I'll probably add an adapter to ramsey/uuid that wraps this
> implementation. The point of the "over engineering" there is to provide
> choice. Some users want to generate bytes from sources other than
> random_bytes() (i.e., libsodium) or encode UUIDs in different ways
> (i.e., ordered time). A UUID generator in the core will only help to
> improve ramsey/uuid, providing more choice and better performance.
>
> I may split out the less-used adapters and codecs into separate
> components in version 4 or 5 of ramsey/uuid, though, since most users
> don't need anything other than the default.
>
> -Ben
>

Yes, exactly.

The provided implementation does not have any of the options your
library offers. There are no special formatters, no accessors for e.g.
time (not applicable to v3, v4, and v5), no RNG choices, no mutability,
... well ... nothing. It is just a straight UUID implementation.

I also hope that this implementation will help to get rid of uniqid at
some point.

--
Richard "Fleshgrinder" Fussenegger
Nikita Popov
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 12:20PM
On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder <[email protected]> wrote:

> On 5/24/2017 10:12 PM, Ben Ramsey wrote:
> > I'll take a look at the patch soon. If this is accepted to the core,
> > I'll probably add an adapter to ramsey/uuid that wraps this
> > implementation. The point of the "over engineering" there is to provide
> > choice. Some users want to generate bytes from sources other than
> > random_bytes() (i.e., libsodium) or encode UUIDs in different ways
> > (i.e., ordered time). A UUID generator in the core will only help to
> > improve ramsey/uuid, providing more choice and better performance.
> >
> > I may split out the less-used adapters and codecs into separate
> > components in version 4 or 5 of ramsey/uuid, though, since most users
> > don't need anything other than the default.
> >
> > -Ben
> >
>
> Yes, exactly.
>
> The provided implementation does not have any of the options your
> library offers. There are no special formatters, no accessors for e.g.
> time (not applicable to v3, v4, and v5), no RNG choices, no mutability,
> ... well ... nothing. It is just a straight UUID implementation.
>
> I also hope that this implementation will help to get rid of uniqid at
> some point.
>
> --
> Richard "Fleshgrinder" Fussenegger
>

I'm wondering if just adding a uuid_v4_create() function (directly
returning a UUID string) might not cover the 95% use case here. My general
impression is that that's what people are usually interested in -- parsing
UUIDs etc. seems to be a rather niche concern.

Nikita
Michał Brzuchalski
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 12:40PM
2017-05-25 12:14 GMT+02:00 Nikita Popov <[email protected]>:

> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder <[email protected]>
> wrote:
>
> > On 5/24/2017 10:12 PM, Ben Ramsey wrote:
> > > I'll take a look at the patch soon. If this is accepted to the core,
> > > I'll probably add an adapter to ramsey/uuid that wraps this
> > > implementation. The point of the "over engineering" there is to provide
> > > choice. Some users want to generate bytes from sources other than
> > > random_bytes() (i.e., libsodium) or encode UUIDs in different ways
> > > (i.e., ordered time). A UUID generator in the core will only help to
> > > improve ramsey/uuid, providing more choice and better performance.
> > >
> > > I may split out the less-used adapters and codecs into separate
> > > components in version 4 or 5 of ramsey/uuid, though, since most users
> > > don't need anything other than the default.
> > >
> > > -Ben
> > >
> >
> > Yes, exactly.
> >
> > The provided implementation does not have any of the options your
> > library offers. There are no special formatters, no accessors for e.g.
> > time (not applicable to v3, v4, and v5), no RNG choices, no mutability,
> > ... well ... nothing. It is just a straight UUID implementation.
> >
> > I also hope that this implementation will help to get rid of uniqid at
> > some point.
> >
> > --
> > Richard "Fleshgrinder" Fussenegger
> >
>
> I'm wondering if just adding a uuid_v4_create() function (directly
> returning a UUID string) might not cover the 95% use case here. My general
> impression is that that's what people are usually interested in -- parsing
> UUIDs etc. seems to be a rather niche concern.
>
> Nikita
>

I've looked on `Ramsey\Uuid` usages in `prooph/event-store`,
`prooph/common` and also
`broadway/broadway` with `broadway/uuid-generator` - most of use cases is
generating
UUID and dumping to string and to bytes. But there is sometimes used
UuidInterface not mentioning
this interface functions, creating Uuid object guarantees the object is
valid UUID which is not true while
using string dumped UUID generated using functions like `uuid_v4_create()`
there's need for
additional check if given string really is a valid UUID - which is not
needed while using specialised object.

--
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 12:50PM
On 5/25/2017 1:01 AM, Sara Golemon wrote:
> On Wed, May 24, 2017 at 11:04 AM, Larry Garfield <[email protected]> wrote:
>> It doesn't have to be a PECL library. I agree that a project requiring a
>> PECL library greatly limits its potential reach, but with Composer
>> user-space libraries are totally easy to install. There's a nice and popular
>> UUID implementation already:
>>
>> https://packagist.org/packages/ramsey/uuid
>>
> This, and entirely this.
>
> There's no justification for doing this in C anymore, we have a high
> level language for tasks like this. It's called PHP.
>
> -Sara
>

Oh, I would do it in PHP, if we could ship it right away with PHP. The
whole idea of an STD is it to provide the most basic building blocks
that are required most often. Otherwise we can simply stop providing
anything together with PHP and let people implement everything in PHP
directly. After all, almost everything can be implemented in userland,
and according to your logic it should.

Every good high-level programming language provides loads of carefully
crafted abstractions. This is to ensure that people can develop faster,
and across different operating systems. Low-level programming languages
often do not do that. Think of C, C++ without boost, or Rust without
STD. This is nice if you are worked on constrained systems that have
like 4 KB of memory, but definitely not when you want to create a
website (still the main target audience of PHP).

UUIDs are an integral part of everything we are using today. The Linux
kernel generates one at the very beginning and uses it as Boot ID. Yeah,
that's how important it is. All of the following languages have UUIDs
built-in:

- Python
- Ruby (1.9+)
- Java (automatically the dialects: Clojure, Groovy, ...)
- .NET (C#, VisualBasic, ...)
- Boost (C++)
- D
- ActionScript 3
- Objective-C
- Swift
- SQL
- ColdFusion
- Cocoa/Carbon
- Wolfram Language
- ...

All operating systems actually come with UUID support out-of-the-box and
use it for various (potentially evil) things.

--
Richard "Fleshgrinder" Fussenegger
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 12:50PM
On 5/25/2017 12:34 PM, Michał Brzuchalski wrote:
> 2017-05-25 12:14 GMT+02:00 Nikita Popov <[email protected]>:
>> I'm wondering if just adding a uuid_v4_create() function (directly
>> returning a UUID string) might not cover the 95% use case here. My general
>> impression is that that's what people are usually interested in -- parsing
>> UUIDs etc. seems to be a rather niche concern.
>>
>> Nikita
>>
>
> I've looked on `Ramsey\Uuid` usages in `prooph/event-store`,
> `prooph/common` and also
> `broadway/broadway` with `broadway/uuid-generator` - most of use cases is
> generating
> UUID and dumping to string and to bytes. But there is sometimes used
> UuidInterface not mentioning
> this interface functions, creating Uuid object guarantees the object is
> valid UUID which is not true while
> using string dumped UUID generated using functions like `uuid_v4_create()`
> there's need for
> additional check if given string really is a valid UUID - which is not
> needed while using specialised object.
>

That is exactly the reason for the class. It is not to be super fancy OO
to be cool. It is for type safety. Strings in PHP are random bytes,
UUIDs are random bytes, how can you distinguish them?

With a UUID type-hint. :)

--
Richard "Fleshgrinder" Fussenegger
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 04:50PM
RFC is finished

https://wiki.php.net/rfc/uuid

--
Richard "Fleshgrinder" Fussenegger
Marco Pivetta
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 05:50PM
Hey Nikita,

On Thu, May 25, 2017 at 12:14 PM, Nikita Popov <[email protected]> wrote:

> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder <[email protected]>
> wrote:
>
>> On 5/24/2017 10:12 PM, Ben Ramsey wrote:
>> > I'll take a look at the patch soon. If this is accepted to the core,
>> > I'll probably add an adapter to ramsey/uuid that wraps this
>> > implementation. The point of the "over engineering" there is to provide
>> > choice. Some users want to generate bytes from sources other than
>> > random_bytes() (i.e., libsodium) or encode UUIDs in different ways
>> > (i.e., ordered time). A UUID generator in the core will only help to
>> > improve ramsey/uuid, providing more choice and better performance.
>> >
>> > I may split out the less-used adapters and codecs into separate
>> > components in version 4 or 5 of ramsey/uuid, though, since most users
>> > don't need anything other than the default.
>> >
>> > -Ben
>> >
>>
>> Yes, exactly.
>>
>> The provided implementation does not have any of the options your
>> library offers. There are no special formatters, no accessors for e.g.
>> time (not applicable to v3, v4, and v5), no RNG choices, no mutability,
>> ... well ... nothing. It is just a straight UUID implementation.
>>
>> I also hope that this implementation will help to get rid of uniqid at
>> some point.
>>
>> --
>> Richard "Fleshgrinder" Fussenegger
>>
>
> I'm wondering if just adding a uuid_v4_create() function (directly
> returning a UUID string) might not cover the 95% use case here. My general
> impression is that that's what people are usually interested in -- parsing
> UUIDs etc. seems to be a rather niche concern.
>
> Nikita
>


I'd say that a good example of how this would change things is the
`DateTime` object.
How many times do you see people passing around `DateTime` objects, and how
many times do you see *valid* (not wordpress) use-case scenarios where a
datetime string is thrown around?

That's the kind of change that a built-in type may trigger here.

I had issues about this due to the squishy behavior of the reflection API
with internal classes, but Richard covered every rough edge, as per
discussion above.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 06:50PM
On 5/25/2017 4:45 PM, Fleshgrinder wrote:
> RFC is finished
>
> https://wiki.php.net/rfc/uuid
>

Would it be possible that we discuss the open issues, instead of trying
to get rid of the proposal completely? I will not back up anyways after
investing so much time. ;)

https://wiki.php.net/rfc/uuid#argument_parsing

The argument parsing is a huge problem together with return type
constraints. Would love some feedback here from nikic. Even if this does
not get included, the issue will pop-up with the next implementation
that wants to use return type constraints.

https://wiki.php.net/rfc/uuid#final_class

I am not sure about the final class modifier. Would love some feedback
here from Ocramius.

https://wiki.php.net/rfc/uuid#namespace

This is more a general thing. I know from many online conversations,
meetups, and conferences that people would love to see it.

https://wiki.php.net/rfc/uuid#doxygen_documentation

I opened a separate thread for that, please answer there.

--
Richard "Fleshgrinder" Fussenegger
Levi Morrison
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 08:00PM
> https://wiki.php.net/rfc/uuid#namespace
>
> This is more a general thing. I know from many online conversations,
> meetups, and conferences that people would love to see it.

My $0.02 is basically what Nikita Popov has said at some point in the past:

The PHP namespace should be reserved for things that are language
oriented, not stuff shipped by default by PHP. For instance a PHP AST
library would appropriately live in the PHP namespace. A UUID library
which has nothing to do with PHP except that's the language we are
using would not be appropriate there.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 25, 2017 08:10PM
On 5/25/2017 7:50 PM, Levi Morrison wrote:
>> https://wiki.php.net/rfc/uuid#namespace
>>
>> This is more a general thing. I know from many online conversations,
>> meetups, and conferences that people would love to see it.
>
> My $0.02 is basically what Nikita Popov has said at some point in the past:
>
> The PHP namespace should be reserved for things that are language
> oriented, not stuff shipped by default by PHP. For instance a PHP AST
> library would appropriately live in the PHP namespace. A UUID library
> which has nothing to do with PHP except that's the language we are
> using would not be appropriate there.
>

Added variations with that to the RFC:

- Core\UUID
- Lang\UUID
- Standard\UUID
- STD\UUID
- UUIDs\UUID

Although I have to say that it seems very weird to me. The conclusion
that the PHP standard module does not belong to PHP makes no sense to
me. I most definitely do not want that my username (vendor) would be
used as a namespace in a core module (I also did not add that to the RFC).

I am also very unsure if that is exactly what Nikita meant back then.

--
Richard "Fleshgrinder" Fussenegger
Sorry, only registered users may post in this forum.

Click here to login