[RFC] [Discussion] UUID

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 library

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

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

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

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

By the way there already is a PECL package for a UUID library:
https://pecl.php.net/package/uuid. I would like to see compelling reasons
why we shouldn't rally around that package
because when you end in a library/extension for each and every trivial
function your codebase becomes a mess - why not PECL i have explained
before the post you quoted and why composer as it is working nwo is a
no-go in the follow-up response

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

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

with every single external dependency that becomes harder

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

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.

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

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.

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