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

[Fleshgrinder]

On 8/20/2017 1:56 PM, Dan Ackroyd wrote:
> On 20 August 2017 at 11:45, Fleshgrinder  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



signature.asc
Description: OpenPGP digital signature

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

[Dan Ackroyd]

On 20 August 2017 at 11:45, Fleshgrinder  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

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

[Marco Pivetta]

On 26 May 2017 10:30 a.m., "Nikita Popov"  wrote:

On Thu, May 25, 2017 at 5:48 PM, Marco Pivetta  wrote:

> Hey Nikita,
>
> On Thu, May 25, 2017 at 12:14 PM, Nikita Popov 
> wrote:
>
>> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder 
>> 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 

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


Agreed: this would be much simpler if the class definition didn't have all
the possible quirks of manually- and C-level defined classes. The fact that
Richard had to test stuff like order of parameters, reflection, etc is,
frankly, frustrating.

Any hope for having the same stubbing of internal classes that HHVM had?
Sara?  

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

[Nikita Popov]

On Fri, May 26, 2017 at 10:34 AM, Fleshgrinder  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
>
>

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

[Nikita Popov]

On Thu, May 25, 2017 at 5:48 PM, Marco Pivetta  wrote:

> Hey Nikita,
>
> On Thu, May 25, 2017 at 12:14 PM, Nikita Popov 
> wrote:
>
>> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder 
>> 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

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

[Marco Pivetta]

On Thu, May 25, 2017 at 6:41 PM, Fleshgrinder  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/

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

[li...@rhsoft.net]

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

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

[Marco Pivetta]

Hey Nikita,

On Thu, May 25, 2017 at 12:14 PM, Nikita Popov  wrote:

> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder 
> 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/

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

[Fleshgrinder]

RFC is finished

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

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Fleshgrinder]

On 5/25/2017 12:34 PM, Michał Brzuchalski wrote:
> 2017-05-25 12:14 GMT+02:00 Nikita Popov :
>> 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



signature.asc
Description: OpenPGP digital signature

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

[Fleshgrinder]

On 5/25/2017 1:01 AM, Sara Golemon wrote:
> On Wed, May 24, 2017 at 11:04 AM, Larry Garfield  
> 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



signature.asc
Description: OpenPGP digital signature

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

[Michał Brzuchalski]

2017-05-25 12:14 GMT+02:00 Nikita Popov :

> On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder 
> 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

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

[Nikita Popov]

On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder  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

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

[Sara Golemon]

On Wed, May 24, 2017 at 11:04 AM, Larry Garfield  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

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

[Ben Ramsey]

On Wed, May 24, 2017 at 2:47 PM, Marco Pivetta  wrote:
>
> On Wed, May 24, 2017 at 8:39 PM, Fleshgrinder  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

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

[Marco Pivetta]

On Wed, May 24, 2017 at 8:39 PM, Fleshgrinder  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/

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature

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

[Jan Ehrhardt]

"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

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

[Marco Pivetta]

On Wed, May 24, 2017 at 8:01 PM, Fleshgrinder  wrote:

> On 5/24/2017 5:11 PM, Levi Morrison wrote:
> > On Wed, May 24, 2017 at 9:04 AM, Larry Garfield 
> > 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/

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

[Fleshgrinder]

On 5/24/2017 5:11 PM, Levi Morrison wrote:
> On Wed, May 24, 2017 at 9:04 AM, Larry Garfield 
> 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



signature.asc
Description: OpenPGP digital signature

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

[li...@rhsoft.net]

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

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

[li...@rhsoft.net]

Am 24.05.2017 um 18:30 schrieb Remi Collet:

Le 24/05/2017 à 17:21, li...@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

[harry@srv-rhsoft:~]$ 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 :-)




Version: 7.1.5

# command 'rpmbuild -bb php.spec --with production' will tune for current hardware while default stays 'sandybridge'
# macro 'php_debug_build' is global (/home/builduser/.rpmmacros) and re-used for pecl-builds while 'debug_build' is local

%global dist  fc%fedora.%(echo $(/usr/bin/date +%Y%m%d.%H%M)).rh
%global phpver7
%global runselftest   0
%global pgo_build 1
%global lto_build 0
%global break_build   0
%global debug_build   0
%global extension_dir %{_libdir}/%{name}/modules

%if %{?_with_production:1}%{!?_with_production:0}
 %global mtune native
 %global rpmsuffix native
 %global php_native_release 1
%else
 %global mtune sandybridge
 %global rpmsuffix sandybridge
 %global php_native_release 0
%endif

%if %php_debug_build
 %global _include_minidebuginfo 1
 %global RH_GCC_DEBUG_OPTION -g3
 %global RH_CONFIGURE_DEBUG_OPTION enable-debug
 %global RH_STRIP_BINARY 0
 %global pgo_build 0
 %global lto_build 0
%else
 %if %debug_build
  %global _include_minidebuginfo 1
  %global RH_GCC_DEBUG_OPTION -g3
  %global RH_CONFIGURE_DEBUG_OPTION enable-debug
  %global RH_STRIP_BINARY 0
  %global pgo_build 0
  %global lto_build 0
 %else
  %global _include_minidebuginfo 0
  %global RH_GCC_DEBUG_OPTION -g0
  %global RH_CONFIGURE_DEBUG_OPTION disable-debug
  %global RH_STRIP_BINARY 1
 %endif
%endif

%if %lto_build
 %global RH_LTO_CONFIGURE_OPTION disable-gcc-global-regs
%else
 %global RH_LTO_CONFIGURE_OPTION enable-gcc-global-regs
%endif

Summary:PHP - CFLAGS: '-m64 -O3 -mfpmath=sse -mavx -msse2avx -march=%{mtune} -mtune=%{mtune} -D_FORTIFY_SOURCE=2 -fdevirtualize-speculatively -fgraphite-identity -fipa-pta -fira-loop-pressure -fivopts -floop-block -floop-unroll-and-jam -fmerge-all-constants -fomit-frame-pointer -fopenmp -fsemantic-interposition -fstack-protector --param=ssp-buffer-size=8 -fstrict-aliasing -ftree-loop-distribution -ftree-loop-if-convert -ftree-loop-if-convert-stores -ftree-loop-im -ftree-loop-ivcanon -fvariable-expansion-in-unroller -fvect-cost-model=unlimited -fwrapv -g0 -minline-all-stringops -pipe -fno-align-labels -fno-exceptions -fno-gcse -fno-math-errno -fno-lto -fuse-ld=gold -fuse-linker-plugin -fprofile-use -Wformat -Werror=format-security -Wno-stack-protector -Wstrict-aliasing -Wa,--noexecstack'
Name:   php
Release:1.%{php_native_release}.%{?dist}.%{rpmsuffix}
License:PHP/Zend/BSD
Group:  Development/Languages
URL:https://secure.php.net/
Source0:php-%{version}.tar.xz
Source1:opcache-zendoptimizer.php
Source2:php-httpd-dummy.conf
Source3:php-disabled-autotests.txt
Source4:php-test-dirs.txt
Source5:php-debug.ini
Patch1: php-realpath-cache-openbasedir.patch
Patch2: 

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

[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?

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Remi Collet]

Le 24/05/2017 à 17:21, li...@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-de...@fedoraproject.org
mailing list.



signature.asc
Description: OpenPGP digital signature

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

[Remi Collet]

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.



signature.asc
Description: OpenPGP digital signature

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

[Levi Morrison]

On Wed, May 24, 2017 at 9:29 AM, li...@rhsoft.net  wrote:

>
>
> Am 24.05.2017 um 17:11 schrieb Levi Morrison:
>
>> On Wed, May 24, 2017 at 9:04 AM, Larry Garfield 
>> wrote:
>>
>> On 05/24/2017 04:31 AM, li...@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.

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

[li...@rhsoft.net]

Am 24.05.2017 um 17:11 schrieb Levi Morrison:

On Wed, May 24, 2017 at 9:04 AM, Larry Garfield 
wrote:


On 05/24/2017 04:31 AM, li...@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 (25 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

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

[li...@rhsoft.net]

Am 24.05.2017 um 17:04 schrieb Larry Garfield:

On 05/24/2017 04:31 AM, li...@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

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

[Levi Morrison]

On Wed, May 24, 2017 at 9:04 AM, Larry Garfield 
wrote:

> On 05/24/2017 04:31 AM, li...@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.

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

[Larry Garfield]

On 05/24/2017 04:31 AM, li...@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

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

[li...@rhsoft.net]

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

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

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

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Fleshgrinder]

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



signature.asc
Description: OpenPGP digital signature