Welcome! Log In Create A New Profile

Advanced

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

Posted by Fleshgrinder 
Am 25.05.2017 um 19:50 schrieb Levi Morrison:
>> 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

frankly - we talk about PHP and not some theoretical language

many people use it *because* things like base64_decode(),
base64_encode(), sha1(), crc32(), crypt(), bin2hex() - what have all
these samles to do with PHP except that's the language we are using?

no - I and many othes don't want to throw tons of 3rd party code and/or
external extension in the mix of their applications

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marco Pivetta
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 26, 2017 01:20AM
On Thu, May 25, 2017 at 6:41 PM, Fleshgrinder <[email protected]> wrote:

> 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


Saw the discussion on github, and I wish that the argument parsing just
behaved like a *NORMAL* PHP method.

The following is perfectly valid:

$crapTonOfUuids = array_map([UUID::class, 'v4'], range(0, 1000));

This would raise a lot of warnings if the API didn't behave like it does in
userland (warning on too many arguments).
A point was raised about BC compliance when adding parameters (future
scope), well here's the news: stop adding arguments to existing functions,
make some damn new functions/methods/classes (to whoever still thinks that
adding arguments is a valid decision).


> 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.
>

The UUID type and specification is simple and clear.
Also, a UUID is a data type with no real behavior.
The only possible and valid scenario for subclassing would be to add
semantic meaning because the developer invented a new type of UUID: that's
to be excluded, as such an implementation (if relevant and secure) would
land in core anyway in future PHP releases.
Subclassing to alter behavior (generation/serialisation, if you want to
call them "behavior") would be a mistake that could even lead to security
issues, and it should be avoided.
This class should be final, so keep it final, IMO.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Nikita Popov
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 26, 2017 10:40AM
On Thu, May 25, 2017 at 5:48 PM, Marco Pivetta <[email protected]> wrote:

> 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.
>

A big difference between DateTime and UUID, is that DateTime has useful
behavior. Apart from unusual cases, there is no need to inspect or modify
the interior of a UUID, while DateTime operations are common and very hard
to implement if not provided by core.

Introducing a UUID class in PHP core as *just* a type safety wrapper feels
akin to adding an EmailAddress class to core. It's certainly not an
unreasonable way to handle things, but imho also not something that should
be in core. We should be providing the primitives based on which people can
implement whichever abstractions they prefer, in a simpler and more
flexible manner than we can achieve in extension code.

Especially if it would allow us to replace a 4kloc diff with one 10loc
function.

Nikita
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 26, 2017 10:40AM
On 5/26/2017 1:08 AM, Marco Pivetta wrote:
> Saw the discussion on github, and I wish that the argument parsing just
> behaved like a *NORMAL* PHP method.
>
> The following is perfectly valid:
>
> $crapTonOfUuids = array_map([UUID::class, 'v4'], range(0, 1000));
>
> This would raise a lot of warnings if the API didn't behave like it does in
> userland (warning on too many arguments).
> A point was raised about BC compliance when adding parameters (future
> scope), well here's the news: stop adding arguments to existing functions,
> make some damn new functions/methods/classes (to whoever still thinks that
> adding arguments is a valid decision).
>

Well, I agree on the adding arguments part. I actually complained a lot
about this in the past.

https://github.com/php/php-src/commit/49aed4fd75e9560444f63593b67fc4ed18e233c9#commitcomment-22277780

I added them because Kalle and Nikita really want to have them. Changing
the return types to be nullable is a complete no-go for me. I am sure
Larry would agree here with me.

The approach I've taken right now would allow one to write:

$crapTonOfUuids = @array_map([UUID::class, 'v4'], range(0, 1000));

As it would emit a warning, but still generate them. Well, unless you
have strict-types mode activated, in that case you would receive the
ArgumentCountError.

I really don't know what the proper solution for this problem is. I
would just leave it out, as I did initially. Nothing bad can happen from
passing too many arguments; not enough should directly lead to an
ArgumentCountError, that's for sure.

On 5/26/2017 1:08 AM, Marco Pivetta wrote:
> The UUID type and specification is simple and clear.
> Also, a UUID is a data type with no real behavior.
> The only possible and valid scenario for subclassing would be to add
> semantic meaning because the developer invented a new type of UUID: that's
> to be excluded, as such an implementation (if relevant and secure) would
> land in core anyway in future PHP releases.
> Subclassing to alter behavior (generation/serialisation, if you want to
> call them "behavior") would be a mistake that could even lead to security
> issues, and it should be avoided.
> This class should be final, so keep it final, IMO.
>
> Marco Pivetta
>

+1

--
Richard "Fleshgrinder" Fussenegger
Nikita Popov
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 26, 2017 11:10AM
On Fri, May 26, 2017 at 10:34 AM, Fleshgrinder <[email protected]> wrote:

> On 5/26/2017 1:08 AM, Marco Pivetta wrote:
> > Saw the discussion on github, and I wish that the argument parsing just
> > behaved like a *NORMAL* PHP method.
> >
> > The following is perfectly valid:
> >
> > $crapTonOfUuids = array_map([UUID::class, 'v4'], range(0, 1000));
> >
> > This would raise a lot of warnings if the API didn't behave like it does
> in
> > userland (warning on too many arguments).
> > A point was raised about BC compliance when adding parameters (future
> > scope), well here's the news: stop adding arguments to existing
> functions,
> > make some damn new functions/methods/classes (to whoever still thinks
> that
> > adding arguments is a valid decision).
> >
>
> Well, I agree on the adding arguments part. I actually complained a lot
> about this in the past.
>
> https://github.com/php/php-src/commit/49aed4fd75e9560444f63593b67fc4
> ed18e233c9#commitcomment-22277780
>
> I added them because Kalle and Nikita really want to have them. Changing
> the return types to be nullable is a complete no-go for me. I am sure
> Larry would agree here with me.
>

To clarify, I certainly do *not* want the behavior that was implemented
here. The correct way (in your specific case) to handle this if by using

if (zend_parse_parameters_throw(ZEND_NUM_ARGS(), "") == FAILURE) {
return;
}

or adding a zend_parse_parameters_none_throw() API.

Of course this should not throw a warning and of course it should not
return NULL, because that would be inconsistent with how the other UUID
methods behave. Of course it should not allow silently passing additional
arguments, because that would be inconsistent with both how the other UUID
methods (with at least one argument) behave and with how PHP in general
behaves.

Nikita


>
> The approach I've taken right now would allow one to write:
>
> $crapTonOfUuids = @array_map([UUID::class, 'v4'], range(0, 1000));
>
> As it would emit a warning, but still generate them. Well, unless you
> have strict-types mode activated, in that case you would receive the
> ArgumentCountError.
>
> I really don't know what the proper solution for this problem is. I
> would just leave it out, as I did initially. Nothing bad can happen from
> passing too many arguments; not enough should directly lead to an
> ArgumentCountError, that's for sure.
>
> On 5/26/2017 1:08 AM, Marco Pivetta wrote:
> > The UUID type and specification is simple and clear.
> > Also, a UUID is a data type with no real behavior.
> > The only possible and valid scenario for subclassing would be to add
> > semantic meaning because the developer invented a new type of UUID:
> that's
> > to be excluded, as such an implementation (if relevant and secure) would
> > land in core anyway in future PHP releases.
> > Subclassing to alter behavior (generation/serialisation, if you want to
> > call them "behavior") would be a mistake that could even lead to security
> > issues, and it should be avoided.
> > This class should be final, so keep it final, IMO.
> >
> > Marco Pivetta
> >
>
> +1
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 26, 2017 12:00PM
On 5/26/2017 10:30 AM, Nikita Popov wrote:
> Especially if it would allow us to replace a 4kloc diff with one 10loc
> function.
>
> Nikita
>

I could remove the provided C API for other modules. Would make the
header file empty and the implementation much shorter. Or at least
remove those that are not of much interest (e.g. php_uuid_get_variant,
php_uuid_get_version, php_uuid_is_nil).

--
Richard "Fleshgrinder" Fussenegger
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 26, 2017 12:00PM
On 5/26/2017 11:00 AM, Nikita Popov wrote:
> To clarify, I certainly do *not* want the behavior that was implemented
> here. The correct way (in your specific case) to handle this if by using
>
> if (zend_parse_parameters_throw(ZEND_NUM_ARGS(), "") == FAILURE) {
> return;
> }
>
> or adding a zend_parse_parameters_none_throw() API.
>
> Of course this should not throw a warning and of course it should not
> return NULL, because that would be inconsistent with how the other UUID
> methods behave. Of course it should not allow silently passing additional
> arguments, because that would be inconsistent with both how the other UUID
> methods (with at least one argument) behave and with how PHP in general
> behaves.
>
> Nikita
>

Thanks for the clarification. I changed the implementation to always
throw. This solves the issue for me. :)

--
Richard "Fleshgrinder" Fussenegger
Marco Pivetta
Re: [PHP-DEV] [RFC] [Discussion] UUID
May 26, 2017 03:30PM
On 26 May 2017 10:30 a.m., "Nikita Popov" <[email protected]> wrote:

On Thu, May 25, 2017 at 5:48 PM, Marco Pivetta <[email protected]> wrote:

> 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.
>

A big difference between DateTime and UUID, is that DateTime has useful
behavior. Apart from unusual cases, there is no need to inspect or modify
the interior of a UUID, while DateTime operations are common and very hard
to implement if not provided by core.

Introducing a UUID class in PHP core as *just* a type safety wrapper feels
akin to adding an EmailAddress class to core. It's certainly not an
unreasonable way to handle things, but imho also not something that should
be in core. We should be providing the primitives based on which people can
implement whichever abstractions they prefer, in a simpler and more
flexible manner than we can achieve in extension code.


Very true, but we're also talking about standardised values that everyone
in userland keep doing wrong in some way. If EmailAddress does ever make it
into core, that's just added value.
Types over string checks all the way
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
August 20, 2017 12:50PM
On 5/24/2017 2:28 AM, Fleshgrinder wrote:
> 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.
>

The class naming [1] issue has been resolved and I withdrew the
namespace RFC [2]. The Doxygen RFC [3] was declined, and I removed all
comments from the sources as well as the stub files.

I would like to start the voting phase the next days, but leave a little
time for further feedback before doing so.

[1] https://wiki.php.net/rfc/class-naming
[2] https://wiki.php.net/rfc/namespaces-in-core
[3] https://wiki.php.net/rfc/doxygen

--
Richard "Fleshgrinder" Fussenegger
Dan Ackroyd
Re: [PHP-DEV] [RFC] [Discussion] UUID
August 20, 2017 02:00PM
On 20 August 2017 at 11:45, Fleshgrinder <[email protected]> wrote:
> On 5/24/2017 2:28 AM, Fleshgrinder wrote:
>
> I would like to start the voting phase the next days, but leave a little
> time for further feedback before doing so.


Perhaps it was clear in your head, but in the context of this email,
it is completely unclear which RFC is the subject of this sentence.

Is it this one?

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

cheers
Dan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [Discussion] UUID
August 20, 2017 02:10PM
On 8/20/2017 1:56 PM, Dan Ackroyd wrote:
> On 20 August 2017 at 11:45, Fleshgrinder <[email protected]> wrote:
>> On 5/24/2017 2:28 AM, Fleshgrinder wrote:
>>
>> I would like to start the voting phase the next days, but leave a little
>> time for further feedback before doing so.
>
>
> Perhaps it was clear in your head, but in the context of this email,
> it is completely unclear which RFC is the subject of this sentence.
>
> Is it this one?
>
> https://wiki.php.net/rfc/uuid
>
> cheers
> Dan
>

Oh, sorry, I thought its clear because I reused the original discussion
thread for it ... yes, it is about https://wiki.php.net/rfc/uuid

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

Click here to login