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
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
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
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 librarybecause 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
On Wed, May 24, 2017 at 9:04 AM, Larry Garfield larry@garfieldtech.com
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 librarybecause 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 packagesIt 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:11 schrieb Levi Morrison:
On Wed, May 24, 2017 at 9:04 AM, Larry Garfield larry@garfieldtech.com
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 librarybecause 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 packagesIt 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
Am 24.05.2017 um 17:11 schrieb Levi Morrison:
On Wed, May 24, 2017 at 9:04 AM, Larry Garfield larry@garfieldtech.com
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 librarybecause 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 packagesIt 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 packagebecause 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.
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.
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
Am 24.05.2017 um 18:35 schrieb Christoph M. Becker:
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)
On Wed, May 24, 2017 at 9:04 AM, Larry Garfield larry@garfieldtech.com
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_bytesdirectly 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
On Wed, May 24, 2017 at 9:04 AM, Larry Garfield larry@garfieldtech.com
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
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 itfinal, so at least we won't
have people extending this thing for no good reason at all :-PMarco 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:
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
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 itfinal, so at least we won't
have people extending this thing for no good reason at all :-PMarco 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 thedefinition.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
finalto ensure that nobody can do anything
with the classes. This applies to theUUIDand theUUIDParseException.
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
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
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'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
2017-05-25 12:14 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:
On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder php@fleshgrinder.com
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" FusseneggerI'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
2017-05-25 12:14 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:
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\Uuidusages inprooph/event-store,
prooph/commonand also
broadway/broadwaywithbroadway/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 likeuuid_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
Hey Nikita,
On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder php@fleshgrinder.com
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" FusseneggerI'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
Hey Nikita,
On Thu, May 25, 2017 at 12:14 PM, Nikita Popov nikita.ppv@gmail.com
wrote:On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder php@fleshgrinder.com
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" FusseneggerI'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
DateTimeobject.
How many times do you see people passing aroundDateTimeobjects, 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
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
Hey Nikita,
On Thu, May 25, 2017 at 12:14 PM, Nikita Popov nikita.ppv@gmail.com
wrote:On Thu, May 25, 2017 at 12:05 PM, Fleshgrinder php@fleshgrinder.com
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" FusseneggerI'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
DateTimeobject.
How many times do you see people passing aroundDateTimeobjects, 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? ?
Am 24.05.2017 um 17:04 schrieb Larry Garfield:
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 librarybecause 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 packagesIt 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
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.
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 containedI 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 :-)
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:
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
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: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
RFC is finished
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
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.
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
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
RFC is finished
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. ;)
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
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.
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.
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
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-22277780I 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.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
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 usingif (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
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
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?
cheers
Dan
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?
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