[VOTE] UUID - Externals

6 years ago by Fleshgrinder — view source

unread

Hello Internals!

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Niklas Keller — view source

unread

Hello Internals!

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

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

6 years ago by Fleshgrinder — view source

unread

Hello Internals!

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

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

This is the second time that I forget the link, stupid me. Thanks a lot. :)

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Zeev Suraski — view source

unread

I just voted 'no', and I'd like to quickly explain why:

I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.
I think a renewed discussion, beyond the two days of discussion 3+ months ago would be useful, as beyond that basic (yet important) point - I have thoughts about a bunch of things in the RFC, and honestly didn't even notice the brief discussion months ago (if there was another one then my apologies, I couldn't find it).
I think that a function that returns a string (a-la uuid_v4_create() Nikita proposed) would make perfect sense. Forcing the use of classes/objects in such a case - where there's little to no added value, is wrong and uncommon (possibly unprecedented) in PHP.
The section dealing with backwards incompatible changes, states:
"Both UUID and UUIDParseException are now globally defined classes, which might collide with user defined classes of the same name in the global namespace. However, the risk of the introduction of them is considered to be very low, since the global namespace should not be used by PHP users."
... erroneously assumes that all code in PHP utilizes namespaces. IMHO this is a projection of a particular coding style onto the entire PHP userbase. We haven't deprecated at any point the ability to place user classes in the global namespace, we haven't even as much as said at any point we might be considering it - and I don't think we should, either. My gut feel, backed by a quick Google search refutes the assumption that the risk of introducing - at least the UUID class - is very low. Not that I have a better suggestion (other than not introducing a class at all) - but I think the text there should be changed as it does not reflect reality.
If I voted yes, it would also mean I agree with a statement such as "One could argue that it is faster (C implementation), which it probably is, but this is a weak argument". I disagree it's a weak argument - and I do think that for basic building blocks of the language, performance absolutely matters. If we manage to get JIT out the door and the performance differences become negligible - then I see a lot of value in moving some of our core value to PHP - but not before then.
Given we seem to agree this is a basic building block of the language (as it is in other languages), I do think it should be a 2/3 majority vote and not a 50%+1 one. Taking the "is this something we can easily change w/o affecting BC" test, this clearly gets a 'no'.

To summarize - I'm strongly in favor of fixing this issue in PHP, but at the same time against the proposed solution. I'd vote in favor of something along the lines of uuid_v4_create() in a heartbeat.

Zeev

-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com]
Sent: שבת 02 ספטמבר 2017 10:02
To: php-internals internals@lists.php.net
Subject: [PHP-DEV] [VOTE] UUID

Hello Internals!

I just started the voting for the inclusion of a UUID value object in PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick the whole week.

The voting is open starting now and until September 16. (2 weeks).

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Fleshgrinder — view source

unread

Hey Zeev :)

I just voted 'no', and I'd like to quickly explain why:

I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.

I think a renewed discussion, beyond the two days of discussion 3+ months ago would be useful, as beyond that basic (yet important) point - I have thoughts about a bunch of things in the RFC, and honestly didn't even notice the brief discussion months ago (if there was another one then my apologies, I couldn't find it).

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

I think that a function that returns a string (a-la uuid_v4_create() Nikita proposed) would make perfect sense. Forcing the use of classes/objects in such a case - where there's little to no added value, is wrong and uncommon (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

The section dealing with backwards incompatible changes, states:
"Both UUID and UUIDParseException are now globally defined classes, which might collide with user defined classes of the same name in the global namespace. However, the risk of the introduction of them is considered to be very low, since the global namespace should not be used by PHP users."
... erroneously assumes that all code in PHP utilizes namespaces. IMHO this is a projection of a particular coding style onto the entire PHP userbase. We haven't deprecated at any point the ability to place user classes in the global namespace, we haven't even as much as said at any point we might be considering it - and I don't think we should, either. My gut feel, backed by a quick Google search refutes the assumption that the risk of introducing - at least the UUID class - is very low. Not that I have a better suggestion (other than not introducing a class at all) - but I think the text there should be changed as it does not reflect reality.

The very same would be true for any function that is being introduced in
the global namespace. I had an RFC for namespaces prepared and ready for
vote; incl. a namespaced UUID implementation. However, the feedback on
it was so extremely negative and hostile that I decided to withdraw it.

If I voted yes, it would also mean I agree with a statement such as "One could argue that it is faster (C implementation), which it probably is, but this is a weak argument". I disagree it's a weak argument - and I do think that for basic building blocks of the language, performance absolutely matters. If we manage to get JIT out the door and the performance differences become negligible - then I see a lot of value in moving some of our core value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

Given we seem to agree this is a basic building block of the language (as it is in other languages), I do think it should be a 2/3 majority vote and not a 50%+1 one. Taking the "is this something we can easily change w/o affecting BC" test, this clearly gets a 'no'.

Actually we can. Both classes are final and users cannot extend them.
The only thing we cannot do is rename the stuff that's already in them.
This is one of the reasons why I kept the provided functionality to a
bare minimum.

To summarize - I'm strongly in favor of fixing this issue in PHP, but at the same time against the proposed solution. I'd vote in favor of something along the lines of uuid_v4_create() in a heartbeat.

$bin = \UUID::v4()->toBinary();
$hex = \UUID::v4()->toHex();
$str = \UUID::v4()->toString();

You can already use it like you want, with greater possibilities and
freedom. Incl. auto-completion with your favorite editor to explore your
possibilities, and type-safety everywhere as an opt-in.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Christoph M. Becker — view source

unread

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

IMHO, the RFC misses its own point. The introduction claims that
uniqid() is insufficient, and that UUIDs are much more appropriate. I
fully agree. However, instead of providing a single function to replace
uniqid() it offers a full blown class which even includes parsing of
UUIDs. The RFC furthermore claims:

| A programming language’s standard module should provide the most basic
| and repeating building blocks, to ensure that developers can achieve
| things fast without much hassle.

I fully agree, but I don't see that parsing of UUIDs is such a most
basic building block, and even most of the rest of the proposed UUID
class doesn't appear to fit that category.

With regard to type-safety (which is probably the point of parse()):
having type-safe UUIDs is only a fraction of one percent of what is
occasionally needed in applications – do we really want to add thousands
of classes to ext/standard?

--
Christoph M. Becker

6 years ago by Remi Collet — view source

unread

Le 02/09/2017 à 09:01, Fleshgrinder a écrit :

Hello Internals!

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

IMHO such a new thing should follow the common process to go to pecl
first, and then merged in some new PHP version (like sodium)

So -1 from me

Remi

6 years ago by Sammy Kaye Powers — view source

unread

I really, really wanted to vote yes for this as I've wanted simple
UUID creation in core for a long time, but I can't agree this is the
correct implementation. Something like "uuid_v4_create()" seems to
make a lot more pragmatic sense and use ramsey/uuid for anything more
complicated.

Sorry Richard, but I'm -1 on this one. But thanks for putting in all
the effort! I think another attempt with a simpler API &
implementation could be a winner! :)

Thanks,
Sammy Kaye Powers
sammyk.me

Hello Internals!

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Arvids Godjuks — view source

unread

2017-09-04 19:03 GMT+03:00 Sammy Kaye Powers me@sammyk.me:

I really, really wanted to vote yes for this as I've wanted simple
UUID creation in core for a long time, but I can't agree this is the
correct implementation. Something like "uuid_v4_create()" seems to
make a lot more pragmatic sense and use ramsey/uuid for anything more
complicated.

Sorry Richard, but I'm -1 on this one. But thanks for putting in all
the effort! I think another attempt with a simpler API &
implementation could be a winner! :)

Thanks,
Sammy Kaye Powers
sammyk.me

Hello everyone, it's been a while.

As a userland dev, I completely agree with the RFC. The implementation
details may be worked out a bit, but having UUID's as an object is a good
thing and having a proper reference implementation that follows the
standard to the letter is very valuable. UUID's are a universal concept,
used in so many systems across the IT world, that I personally consider
them to be a thing on their own. I do believe they deserve to be an object

if you expect a UUID, you want a very specific thing, not just a generic
string and then validate it every time with some form of
"is_valid_uuid($uuid)". Even if PHP will have a reference implementation,
99.9% chance I will use a wrapper library that will give me an object I can
work with. And not only for my personal preference, but also so other
people working on the same project do not mess with a UUID string. Type
hinting checks are also quite important, that I learned first hand lately
as I went PHP 7.1 strict_types=1 on my whole codebase - I have been passing
crap to in places that I would have never known, and probably would never
result in an issue due to the nature of the error.

I do, however, think that maybe doing a userland PHP implementation of the
proposed module, so people can play and use it and then converting it to a
PHP C module closer to 7.3 would be a better way. That way the API and
features can be stabilized.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

6 years ago by Stephen Reay — view source

unread

That way the API and
features can be stabilized.

(Sorry for resend, just realised I sent from a non-list email)

Hi Arvids,

This is exactly why I (and possibly others) are in favour of this being implemented as a few functions - the object side of things can then be left to a user land implementation, which is much easier to update and refine.

Cheers

Stephen

6 years ago by Andreas Heigl — view source

unread

Am 02.09.17 um 09:01 schrieb Fleshgrinder:

Hello Internals!

I just started the voting for the inclusion of a UUID value object in
PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
the whole week.

The voting is open starting now and until September 16. (2 weeks).

Hey Richard, Hey all.

Thanks for putting up the RFC and the implementation!

Having UUIDs in the core would be awesome. One of the reasons would be
that it's in C. That'd be faster but would also allow easier integration
with system-calls to be easier able to get the MAC-Address for a type-1
UUID f.e.

But why limit UUIDs to type 3 through 5? Having security in mind is good
IMHO but not implementing type 1 and 2 limits the usability and
therefore the usefullness. Let the users decide whether they need it or
not. As long as people can create SQL-Injections in PHP we should not
use the security argument to limit usability or not implement
standardized functionality.

Especially when there is a full-fledged reference-implementation in
userland available. In the RFC you reference ramsey/uuid yourself. But
why should one use the internal UUID-class/functionality when there is a
more powerful one in userland available?

And limiting the usability and extendability of the UUID-Class itself by
declaring it final means that userland-code can only wrap the class but
not extend it. So userland code can not typehint for the UUID-class when
special features are necessary that would need extending the class. And
as there's no interface, I can't typehint for that either.

So all in all for me that's

less functionality than the reference-implementation
missing UUID-types (the ones that are easier to implement in C)
missing extendability

and a naging feeling that the imlementation decides what I as a user
actually need.

That's why I can't vote "yes".

Sorry.

Thanks for putting in the effort and coming up with a first implementation.

Cheers

Andreas

PS: Personally I don't like a "uuid_4_create" as that would also mean
there should be a "uuid_1_create" through "uuid_5_create" as well and
then there also would need to be a "uuid_1_verify" through "uuid_5_verify"…

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+

6 years ago by Fleshgrinder — view source

unread

Hey Richard, Hey all.

Thanks for putting up the RFC and the implementation!

Having UUIDs in the core would be awesome. One of the reasons would be
that it's in C. That'd be faster but would also allow easier integration
with system-calls to be easier able to get the MAC-Address for a type-1
UUID f.e.

But why limit UUIDs to type 3 through 5? Having security in mind is good
IMHO but not implementing type 1 and 2 limits the usability and
therefore the usefullness. Let the users decide whether they need it or
not. As long as people can create SQL-Injections in PHP we should not
use the security argument to limit usability or not implement
standardized functionality.

Especially when there is a full-fledged reference-implementation in
userland available. In the RFC you reference ramsey/uuid yourself. But
why should one use the internal UUID-class/functionality when there is a
more powerful one in userland available?

And limiting the usability and extendability of the UUID-Class itself by
declaring it final means that userland-code can only wrap the class but
not extend it. So userland code can not typehint for the UUID-class when
special features are necessary that would need extending the class. And
as there's no interface, I can't typehint for that either.

So all in all for me that's

less functionality than the reference-implementation

missing UUID-types (the ones that are easier to implement in C)

missing extendability

and a naging feeling that the imlementation decides what I as a user
actually need.

That's why I can't vote "yes".

Sorry.

Thanks for putting in the effort and coming up with a first implementation.

Cheers

Andreas

PS: Personally I don't like a "uuid_4_create" as that would also mean
there should be a "uuid_1_create" through "uuid_5_create" as well and
then there also would need to be a "uuid_1_verify" through "uuid_5_verify"…

Hi Andreas!

Thanks for your feedback.

We can easily add v1 and v2 because the class is final. It would not be
a breaking change, or anything. v2 is pretty much useless imho, but v1
if done right would not even harm your privacy.

Composition is more powerful than inheritance. You mention that you
cannot extend it to add functionality, at the same time you want to
type-hint against it. Well, in order to use the extended functionality
you need to type-hint against your extended version. Hence, there is
zero value for you in extending it other than having some place using
the extended version, and others the core version without noticing that
it got the extended version.

The thing is, you should create your own value objects for your
identifiers and hide the fact what it wraps. In C, and many other
languages, we have type aliases. In PHP, and many other OO languages, we
use composition to achieve that.

Whether to make it final or not was discussed, and especially Ocramius
agreed with me on this. I believe that it is the right choice.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Andreas Heigl — view source

unread

Hey Richard

Am 05.09.17 um 19:29 schrieb Fleshgrinder:

Hey Richard, Hey all.

Thanks for putting up the RFC and the implementation!

Having UUIDs in the core would be awesome. One of the reasons would be
that it's in C. That'd be faster but would also allow easier integration
with system-calls to be easier able to get the MAC-Address for a type-1
UUID f.e.

But why limit UUIDs to type 3 through 5? Having security in mind is good
IMHO but not implementing type 1 and 2 limits the usability and
therefore the usefullness. Let the users decide whether they need it or
not. As long as people can create SQL-Injections in PHP we should not
use the security argument to limit usability or not implement
standardized functionality.

Especially when there is a full-fledged reference-implementation in
userland available. In the RFC you reference ramsey/uuid yourself. But
why should one use the internal UUID-class/functionality when there is a
more powerful one in userland available?

And limiting the usability and extendability of the UUID-Class itself by
declaring it final means that userland-code can only wrap the class but
not extend it. So userland code can not typehint for the UUID-class when
special features are necessary that would need extending the class. And
as there's no interface, I can't typehint for that either.

So all in all for me that's

less functionality than the reference-implementation

missing UUID-types (the ones that are easier to implement in C)

missing extendability

and a naging feeling that the imlementation decides what I as a user
actually need.

That's why I can't vote "yes".

Sorry.

Thanks for putting in the effort and coming up with a first implementation.

Cheers

Andreas

PS: Personally I don't like a "uuid_4_create" as that would also mean
there should be a "uuid_1_create" through "uuid_5_create" as well and
then there also would need to be a "uuid_1_verify" through "uuid_5_verify"…

Hi Andreas!

Thanks for your feedback.

We can easily add v1 and v2 because the class is final. It would not be
a breaking change, or anything. v2 is pretty much useless imho, but v1
if done right would not even harm your privacy.

I'm with you there in so far that I personally don't see a value in a
type 2 UUID. But there might be people that need exactly that. And as
adding functionality usually isn't a BC-break that's OK.

Composition is more powerful than inheritance. You mention that you
cannot extend it to add functionality, at the same time you want to
type-hint against it. Well, in order to use the extended functionality
you need to type-hint against your extended version. Hence, there is
zero value for you in extending it other than having some place using
the extended version, and others the core version without noticing that
it got the extended version.

I'm well aware of that and perhaps I didn't express myself as clear as I
should have.

Imagine a use-case where a UUID-class is needed. But alongside the
toString, toHex and toBinary there's also the need for a further
function (let's call it toArray). So currently I need to create a
wrapper arround UUID that then needs to implement all the public methods
of UUID as well as the new toArray. So it works identically to UUID but
it isn't UUID. And I have no way of using my own UUID-Class - as it
doesnt' extend UUID - as replacement for UUID. I'd need to expose the
wrapped UUID-Class to be able to retrieve it whenever some libray
expects a UUID. Perhaps this gist can make it clearer:
https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa

The thing is, you should create your own value objects for your
identifiers and hide the fact what it wraps. In C, and many other
languages, we have type aliases. In PHP, and many other OO languages, we
use composition to achieve tha>
Whether to make it final or not was discussed, and especially Ocramius
agreed with me on this. I believe that it is the right choice.

I'm not saying it's the wrong choice. I for myself would probably not
immediately use it as the ramsey/uuid-package is widely in use, but I
could f.e. think, that that package might start to use the UUID-class
under the hood. And then that would be a case where extending could be
helpful as a \Ramsey\UUID would be an instance of \UUID.

The alternative would be to implement a UUIDInterface that exposes the
relevant methods and that would be implemented by \UUID itself.

But that's just my 0.02€

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+

6 years ago by Fleshgrinder — view source

unread

I'm well aware of that and perhaps I didn't express myself as clear as I
should have.

Imagine a use-case where a UUID-class is needed. But alongside the
toString, toHex and toBinary there's also the need for a further
function (let's call it toArray). So currently I need to create a
wrapper arround UUID that then needs to implement all the public methods
of UUID as well as the new toArray. So it works identically to UUID but
it isn't UUID. And I have no way of using my own UUID-Class - as it
doesnt' extend UUID - as replacement for UUID. I'd need to expose the
wrapped UUID-Class to be able to retrieve it whenever some libray
expects a UUID. Perhaps this gist can make it clearer:
https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa

I'm not saying it's the wrong choice. I for myself would probably not
immediately use it as the ramsey/uuid-package is widely in use, but I
could f.e. think, that that package might start to use the UUID-class
under the hood. And then that would be a case where extending could be
helpful as a \Ramsey\UUID would be an instance of \UUID.

The alternative would be to implement a UUIDInterface that exposes the
relevant methods and that would be implemented by \UUID itself.

But that's just my 0.02€

Cheers

Andreas

OK, now I understand it better. I would argue that if we really find
something existential that should be added, we should add it to the UUID
class itself.

See, the problem with allowing extension is that we have a real BC
issue. All your arguments are well received and correct, but the open a
can of worms that is impossible to close. Keeping it final ensures that
this cannot happen, ever. We can continue to refine without breaking
anyone. I think it also was Ocramius who released a nice article about
"final first", but there are probably many from the Java world.

Btw. the interface does not really make sense. Interfaces are for
polymorphism, in other words, if there are different implementations of
the same thing that should be usable interchangeably. This is definitely
not the case with UUIDs, the algorithm is set in stone. Don't forget
that you can instantiate any kind of UUID with the fromBinary method,
so you can easily generate different UUIDs on your own and still use the
built-in class; no need for extension.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Niklas Keller — view source

unread

Hey Richard

Am 05.09.17 um 19:29 schrieb Fleshgrinder:

Hey Richard, Hey all.

Thanks for putting up the RFC and the implementation!

Having UUIDs in the core would be awesome. One of the reasons would be
that it's in C. That'd be faster but would also allow easier integration
with system-calls to be easier able to get the MAC-Address for a type-1
UUID f.e.

But why limit UUIDs to type 3 through 5? Having security in mind is good
IMHO but not implementing type 1 and 2 limits the usability and
therefore the usefullness. Let the users decide whether they need it or
not. As long as people can create SQL-Injections in PHP we should not
use the security argument to limit usability or not implement
standardized functionality.

Especially when there is a full-fledged reference-implementation in
userland available. In the RFC you reference ramsey/uuid yourself. But
why should one use the internal UUID-class/functionality when there is a
more powerful one in userland available?

And limiting the usability and extendability of the UUID-Class itself by
declaring it final means that userland-code can only wrap the class but
not extend it. So userland code can not typehint for the UUID-class when
special features are necessary that would need extending the class. And
as there's no interface, I can't typehint for that either.

So all in all for me that's

less functionality than the reference-implementation

missing UUID-types (the ones that are easier to implement in C)

missing extendability

and a naging feeling that the imlementation decides what I as a user
actually need.

That's why I can't vote "yes".

Sorry.

Thanks for putting in the effort and coming up with a first
implementation.

Cheers

Andreas

PS: Personally I don't like a "uuid_4_create" as that would also mean
there should be a "uuid_1_create" through "uuid_5_create" as well and
then there also would need to be a "uuid_1_verify" through
"uuid_5_verify"…

Hi Andreas!

Thanks for your feedback.

We can easily add v1 and v2 because the class is final. It would not be
a breaking change, or anything. v2 is pretty much useless imho, but v1
if done right would not even harm your privacy.

I'm with you there in so far that I personally don't see a value in a
type 2 UUID. But there might be people that need exactly that. And as
adding functionality usually isn't a BC-break that's OK.

Composition is more powerful than inheritance. You mention that you
cannot extend it to add functionality, at the same time you want to
type-hint against it. Well, in order to use the extended functionality
you need to type-hint against your extended version. Hence, there is
zero value for you in extending it other than having some place using
the extended version, and others the core version without noticing that
it got the extended version.

I'm well aware of that and perhaps I didn't express myself as clear as I
should have.

Imagine a use-case where a UUID-class is needed. But alongside the
toString, toHex and toBinary there's also the need for a further
function (let's call it toArray). So currently I need to create a
wrapper arround UUID that then needs to implement all the public methods
of UUID as well as the new toArray. So it works identically to UUID but
it isn't UUID. And I have no way of using my own UUID-Class - as it
doesnt' extend UUID - as replacement for UUID. I'd need to expose the
wrapped UUID-Class to be able to retrieve it whenever some libray
expects a UUID. Perhaps this gist can make it clearer:
https://gist.github.com/heiglandreas/452dae591d071cbdfb78b431cb6597fa

How about a simple function that takes an UUID and returns what you want?
People often forget that they exist in PHP.

Regards, Niklas

The thing is, you should create your own value objects for your
identifiers and hide the fact what it wraps. In C, and many other
languages, we have type aliases. In PHP, and many other OO languages, we
use composition to achieve tha>
Whether to make it final or not was discussed, and especially Ocramius
agreed with me on this. I believe that it is the right choice.

I'm not saying it's the wrong choice. I for myself would probably not
immediately use it as the ramsey/uuid-package is widely in use, but I
could f.e. think, that that package might start to use the UUID-class
under the hood. And then that would be a case where extending could be
helpful as a \Ramsey\UUID would be an instance of \UUID.

The alternative would be to implement a UUIDInterface that exposes the
relevant methods and that would be implemented by \UUID itself.

But that's just my 0.02€

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+

6 years ago by Zeev Suraski — view source

unread

I just voted 'no', and I'd like to quickly explain why:

I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.

I think a renewed discussion, beyond the two days of discussion 3+ months ago would be useful, as beyond that basic (yet important) point - I have thoughts about a bunch of things in the RFC, and honestly didn't even notice the brief discussion months ago (if there was another one then my apologies, I couldn't find it).

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

As far as I'm concerned the only relevant discussion is on internals. It's ok to use other mediums (although personally I think it's not very positive) - as long as they're ultimately represented on internals.

My quick search suggested there was only roughly two days worth of discussion sometime in May, but it's possible I wasn't thorough in searching.

I think that a function that returns a string (a-la uuid_v4_create() Nikita proposed) would make perfect sense. Forcing the use of classes/objects in such a case - where there's little to no added value, is wrong and uncommon (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

Not really - all of those give substantial value that can't really be provided without a class. Not so with UUID - I'm quite with Nikita when he says that 95% of the value can be had with a single function call - it's therefore not a good candidate for mandatory object wrapping.

The section dealing with backwards incompatible changes, states:
"Both UUID and UUIDParseException are now globally defined classes, which might collide with user defined classes of the same name in the global namespace. However, the risk of the introduction of them is considered to be very low, since the global namespace should not be used by PHP users."
... erroneously assumes that all code in PHP utilizes namespaces. IMHO this is a projection of a particular coding style onto the entire PHP userbase. We haven't deprecated at any point the ability to place user classes in the global namespace, we haven't even as much as said at any point we might be considering it - and I don't think we should, either. My gut feel, backed by a quick Google search refutes the assumption that the risk of introducing - at least the UUID class - is very low. Not that I have a better suggestion (other than not introducing a class at all) - but I think the text there should be changed as it does not reflect reality.

The very same would be true for any function that is being introduced in
the global namespace. I had an RFC for namespaces prepared and ready for
vote; incl. a namespaced UUID implementation. However, the feedback on
it was so extremely negative and hostile that I decided to withdraw it.

Rightfully so - I don't think a UUID namespace is the answer as it's an overkill. But UUID isn't just a global class name - it's actually a global class name that's not that unlikely to exist in apps and collide with them (as opposed to, say, UUIDParseException). At minimum the comment about the risk being very low, as well as the personal preference not to have user classes in the global namespace should be removed, imho, even if we can't come up with a better name. It may be that sticking with the UUID class name is the right choice (if we pick the wrong choice of introducing a class and not a function :-) but we should be accurate and upfront as to why we think it's ok.

If I voted yes, it would also mean I agree with a statement such as "One could argue that it is faster (C implementation), which it probably is, but this is a weak argument". I disagree it's a weak argument - and I do think that for basic building blocks of the language, performance absolutely matters. If we manage to get JIT out the door and the performance differences become negligible - then I see a lot of value in moving some of our core value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

Where's the poll / vote that most people think differently?
Either way, even if it can be argued that for this particular case performance is a weak argument (which is debatable), it's most certainly not an inherently weak argument as the current wording implies. There shouldn't be a ratified PHP RFC implying that performance considerations are weak arguments, without clear context and explanation.

Given we seem to agree this is a basic building block of the language (as it is in other languages), I do think it should be a 2/3 majority vote and not a 50%+1 one. Taking the "is this something we can easily change w/o affecting BC" test, this clearly gets a 'no'.

Actually we can. Both classes are final and users cannot extend them.
The only thing we cannot do is rename the stuff that's already in them.
This is one of the reasons why I kept the provided functionality to a
bare minimum.

Regardless of being final, they'll become a basic building block in apps, and taking them away or modifying them means substantial breakage. The very introduction of the class, its name (and to a lesser degree its functionality) - are tickets with remarkably expensive cancelation options.

Zeev

6 years ago by Fleshgrinder — view source

unread

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

As far as I'm concerned the only relevant discussion is on internals. It's ok to use other mediums (although personally I think it's not very positive) - as long as they're ultimately represented on internals.

My quick search suggested there was only roughly two days worth of discussion sometime in May, but it's possible I wasn't thorough in searching.

What I wanted to say is that the discussion was not held secretly, on
the contrary, it was very loud on many channels. I am not sure what you
want from me, because everything followed the officially prescribed
procedures. Not sure if I can be blamed that some people missed it. I
asked for additional feedback not two weeks ago before I started the vote.

On 9/2/2017 2:26 PM, Zeev Suraski wrote:> Not really - all of those give
substantial value that can't really be provided without a class. Not so
with UUID - I'm quite with Nikita when he says that 95% of the value can
be had with a single function call - it's therefore not a good candidate
for mandatory object wrapping.

Type safety alone is such a substantial value to me, and many others,
that it is reason enough to go for the class. This is also my argument
in the RFC, and I stand by it.

Rightfully so - I don't think a UUID namespace is the answer as it's an overkill. But UUID isn't just a global class name - it's actually a global class name that's not that unlikely to exist in apps and collide with them (as opposed to, say, UUIDParseException). At minimum the comment about the risk being very low, as well as the personal preference not to have user classes in the global namespace should be removed, imho, even if we can't come up with a better name. It may be that sticking with the UUID class name is the right choice (if we pick the wrong choice of introducing a class and not a function :-) but we should be accurate and upfront as to why we think it's ok.

I did not propose a UUID namespace, that is what others from Internals
wanted. My namespace proposal is much greater than that. However, the
feedback was one-sided and hostile, so that I decided to withdraw the
RFC, and seriously think about why I should continue contributing to PHP.

https://wiki.php.net/rfc/namespaces-in-core

Where's the poll / vote that most people think differently?
Either way, even if it can be argued that for this particular case performance is a weak argument (which is debatable), it's most certainly not an inherently weak argument as the current wording implies. There shouldn't be a ratified PHP RFC implying that performance considerations are weak arguments, without clear context and explanation.

The people were the ones here on Internals. Read the discussion thread
again. I gladly change the wording, because I also think that
performance is a valid argument, but did not feel like it would be
accepted. Hence, the wording.

Regardless of being final, they'll become a basic building block in apps, and taking them away or modifying them means substantial breakage. The very introduction of the class, its name (and to a lesser degree its functionality) - are tickets with remarkably expensive cancelation options.

Zeev

This is true for any addition to the language, and imho not an argument
against the inclusion of new features. I did my very best to create a
good API that is useful in daily life. I understand that you prefer
procedural programming, and I understand that you do not see the value
of type safety. I prefer OO, like the majority of today's PHP community,
and I prefer type safety, and the implementation is the result of these
preferences. Feel free to create procedural aliases, like we have it for
almost all other classes in core. I think one way to do things is
better, but I also know that this is not the PHP way. Confusing APIs and
multiple ways to do the same thing is the status quo. I believe we
should break out of that, and cleanup, but many others don't ... alas.
Another reason to leave PHP behind.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com]
Sent: Sunday, September 3, 2017 10:17 AM
To: Zeev Suraski zeev@zend.com; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

As far as I'm concerned the only relevant discussion is on internals. It's ok to
use other mediums (although personally I think it's not very positive) - as long
as they're ultimately represented on internals.

My quick search suggested there was only roughly two days worth of
discussion sometime in May, but it's possible I wasn't thorough in searching.

What I wanted to say is that the discussion was not held secretly, on the
contrary, it was very loud on many channels. I am not sure what you want from
me, because everything followed the officially prescribed procedures. Not sure
if I can be blamed that some people missed it. I asked for additional feedback
not two weeks ago before I started the vote.

Richard,

I'm not accusing you of anything. This is all in positive constructive spirit, and I was the first to admit I may have missed something - and although at this point I don't think I did, that's still a possibility.

My point is simple - when I saw the vote, I looked for the prior discussion on internals - which is the only official channel for discussing these matters. The only discussion I could find took place between May 24 and May 26 - i.e. well over 3 months ago. While being intense, it raised good points which remained unanswered, and it died out very quickly without any sort of followup. Again, I have no idea what kind of discussion happened on reddit or IRC or other channels, but that shouldn't matter.

Type safety alone is such a substantial value to me, and many others, that it is
reason enough to go for the class. This is also my argument in the RFC, and I
stand by it.

That's great, but given that it's unprecedented, it's not a very good argument. To quote Marco from the May discussion:
"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."

Where's the poll / vote that most people think differently?
Either way, even if it can be argued that for this particular case performance
is a weak argument (which is debatable), it's most certainly not an inherently
weak argument as the current wording implies. There shouldn't be a ratified
PHP RFC implying that performance considerations are weak arguments,
without clear context and explanation.

The people were the ones here on Internals. Read the discussion thread again. I
gladly change the wording, because I also think that performance is a valid
argument, but did not feel like it would be accepted. Hence, the wording.

There's a difference between certain people saying something, and 'most people think'. There were only about 15 people that participated in this thread, and of those, I couldn't find any that said that performance is a weak argument. Most didn't comment about performance at all.

I could find some that said the opposite, including Ben Ramsey:
"A UUID generator in the core will only help to improve ramsey/uuid, providing more choice and better performance."
The 'only' there might be confusing, but it's intended in a positive way.

I fail to see how it's possible to derive from that thread a statement that 'performance is a weak argument', and I do think it's bad to have a ratified php.net RFC that would make that statement as if it's an obvious truth.

Regardless of being final, they'll become a basic building block in apps, and
taking them away or modifying them means substantial breakage. The very
introduction of the class, its name (and to a lesser degree its functionality) - are
tickets with remarkably expensive cancelation options.

Zeev

This is true for any addition to the language, and imho not an argument against
the inclusion of new features. I did my very best to create a good API that is
useful in daily life. I understand that you prefer procedural programming, and I
understand that you do not see the value of type safety. I prefer OO, like the
majority of today's PHP community, and I prefer type safety, and the
implementation is the result of these preferences. Feel free to create
procedural aliases, like we have it for almost all other classes in core. I think
one way to do things is better, but I also know that this is not the PHP way.
Confusing APIs and multiple ways to do the same thing is the status quo. I
believe we should break out of that, and cleanup, but many others don't ... alas.
Another reason to leave PHP behind.

First, I do not prefer procedural programming. Personally I use OO a lot more than I use procedural. This is, however, completely besides the point - when designing and maintaining PHP, I put my personal preferences aside and try to think about what's right and consistent for the language. I think everyone who contributes should do the same.
Secondly, and very much related, suggesting "I'll do half the job, you can do the other half if you want" is very much the wrong approach IMHO. When introducing a new feature, we should strive to make it consistent across the board, catering to the wide range of users in our community, and not half baked according to the individual preferences of the subsets of the language one likes.
Thirdly, there's nothing inherently confusing about procedural APIs, or inherently clear about OO APIs. Yes, some of our legacy APIs are a mess, and it's a tough problem to tackle - but this has nothing to do with not wanting to introduce a procedural API for creating a UUID. The procedural/OO duality is not at all what people complain about when griping about PHP's API mess.
Last, yes, the rationale is indeed true for most additions to the language. The 2/3 barrier, as is explained in the Voting RFC (wiki.php.net/rfc/voting), has a rationale - the rationale being that unlike changes in apps or frameworks, changes to the language have an immense cost of reversal or incompatible alteration. Adding a top level object that's four letters long falls squarely within that definition - unlike, say, deciding when to release version X, or whether to call version Y "8.0" or "10.0". Looking at it from the other end - fast forward into 2021 a world where the current UUID proposal is accepted as-is, would we feel comfortable deprecating it with 50%+1 majority? If the answer's no, introducing it shouldn't be at 50%+1 either.

Zeev

6 years ago by Marco Pivetta — view source

unread

Hey Zeev,

My issue with having more core classes is just with the fact that
reflection and type system are not working 1:1 like in userland. Richard
fixed that in the PR with extensive testing, so that's fine.

More type safety is definitely a good thing, especially when widely
distributed. Passing around a UUID as a string is surely not something I'd
allow in any kind of codebase I work with: it would be nuked at review.

-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com]
Sent: Sunday, September 3, 2017 10:17 AM
To: Zeev Suraski zeev@zend.com; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

As far as I'm concerned the only relevant discussion is on internals.
It's ok to
use other mediums (although personally I think it's not very positive) -
as long
as they're ultimately represented on internals.

My quick search suggested there was only roughly two days worth of
discussion sometime in May, but it's possible I wasn't thorough in
searching.

What I wanted to say is that the discussion was not held secretly, on the
contrary, it was very loud on many channels. I am not sure what you want
from
me, because everything followed the officially prescribed procedures.
Not sure
if I can be blamed that some people missed it. I asked for additional
feedback
not two weeks ago before I started the vote.

Richard,

I'm not accusing you of anything. This is all in positive constructive
spirit, and I was the first to admit I may have missed something - and
although at this point I don't think I did, that's still a possibility.

My point is simple - when I saw the vote, I looked for the prior
discussion on internals - which is the only official channel for
discussing these matters. The only discussion I could find took place
between May 24 and May 26 - i.e. well over 3 months ago. While being
intense, it raised good points which remained unanswered, and it died out
very quickly without any sort of followup. Again, I have no idea what kind
of discussion happened on reddit or IRC or other channels, but that
shouldn't matter.

Type safety alone is such a substantial value to me, and many others,
that it is
reason enough to go for the class. This is also my argument in the RFC,
and I
stand by it.

That's great, but given that it's unprecedented, it's not a very good
argument. To quote Marco from the May discussion:
"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."

Where's the poll / vote that most people think differently?
Either way, even if it can be argued that for this particular case
performance
is a weak argument (which is debatable), it's most certainly not an
inherently
weak argument as the current wording implies. There shouldn't be a
ratified
PHP RFC implying that performance considerations are weak arguments,
without clear context and explanation.

The people were the ones here on Internals. Read the discussion thread
again. I
gladly change the wording, because I also think that performance is a
valid
argument, but did not feel like it would be accepted. Hence, the wording.

There's a difference between certain people saying something, and 'most
people think'. There were only about 15 people that participated in this
thread, and of those, I couldn't find any that said that performance is a
weak argument. Most didn't comment about performance at all.

I could find some that said the opposite, including Ben Ramsey:
"A UUID generator in the core will only help to improve ramsey/uuid,
providing more choice and better performance."
The 'only' there might be confusing, but it's intended in a positive way.

I fail to see how it's possible to derive from that thread a statement
that 'performance is a weak argument', and I do think it's bad to have a
ratified php.net RFC that would make that statement as if it's an obvious
truth.

Regardless of being final, they'll become a basic building block in
apps, and
taking them away or modifying them means substantial breakage. The very
introduction of the class, its name (and to a lesser degree its
functionality) - are
tickets with remarkably expensive cancelation options.

Zeev

This is true for any addition to the language, and imho not an argument
against
the inclusion of new features. I did my very best to create a good API
that is
useful in daily life. I understand that you prefer procedural
programming, and I
understand that you do not see the value of type safety. I prefer OO,
like the
majority of today's PHP community, and I prefer type safety, and the
implementation is the result of these preferences. Feel free to create
procedural aliases, like we have it for almost all other classes in
core. I think
one way to do things is better, but I also know that this is not the PHP
way.
Confusing APIs and multiple ways to do the same thing is the status quo.
I
believe we should break out of that, and cleanup, but many others don't
... alas.
Another reason to leave PHP behind.

First, I do not prefer procedural programming. Personally I use OO a lot
more than I use procedural. This is, however, completely besides the point

when designing and maintaining PHP, I put my personal preferences aside
and try to think about what's right and consistent for the language. I
think everyone who contributes should do the same.
Secondly, and very much related, suggesting "I'll do half the job, you can
do the other half if you want" is very much the wrong approach IMHO. When
introducing a new feature, we should strive to make it consistent across
the board, catering to the wide range of users in our community, and not
half baked according to the individual preferences of the subsets of the
language one likes.
Thirdly, there's nothing inherently confusing about procedural APIs, or
inherently clear about OO APIs. Yes, some of our legacy APIs are a mess,
and it's a tough problem to tackle - but this has nothing to do with not
wanting to introduce a procedural API for creating a UUID. The
procedural/OO duality is not at all what people complain about when griping
about PHP's API mess.
Last, yes, the rationale is indeed true for most additions to the
language. The 2/3 barrier, as is explained in the Voting RFC (
wiki.php.net/rfc/voting), has a rationale - the rationale being that
unlike changes in apps or frameworks, changes to the language have an
immense cost of reversal or incompatible alteration. Adding a top level
object that's four letters long falls squarely within that definition -
unlike, say, deciding when to release version X, or whether to call version
Y "8.0" or "10.0". Looking at it from the other end - fast forward into
2021 a world where the current UUID proposal is accepted as-is, would we
feel comfortable deprecating it with 50%+1 majority? If the answer's no,
introducing it shouldn't be at 50%+1 either.

Zeev

6 years ago by Fleshgrinder — view source

unread

Richard,

I'm not accusing you of anything. This is all in positive constructive spirit, and I was the first to admit I may have missed something - and although at this point I don't think I did, that's still a possibility.

Sorry, than I misunderstood. I interpreted it in the way that you meant
that I did something wrong by bringing this to vote.

My point is simple - when I saw the vote, I looked for the prior discussion on internals - which is the only official channel for discussing these matters. The only discussion I could find took place between May 24 and May 26 - i.e. well over 3 months ago. While being intense, it raised good points which remained unanswered, and it died out very quickly without any sort of followup. Again, I have no idea what kind of discussion happened on reddit or IRC or other channels, but that shouldn't matter.

Maybe I should stop the vote. The discussion is happening now instead of
before when I asked for it. We'll have to wait for at least six months
for another vote if this is a no, due to the rules.

That's great, but given that it's unprecedented, it's not a very good argument. To quote Marco from the May discussion:
"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."

I disagree with that comment. I think that PHP is a high-level language,
and thus should provide high-level abstractions that fulfill the most
basic needs. A UUID is not a string, I'll go into this below.

There's a difference between certain people saying something, and 'most people think'. There were only about 15 people that participated in this thread, and of those, I couldn't find any that said that performance is a weak argument. Most didn't comment about performance at all.

I could find some that said the opposite, including Ben Ramsey:
"A UUID generator in the core will only help to improve ramsey/uuid, providing more choice and better performance."
The 'only' there might be confusing, but it's intended in a positive way.

I fail to see how it's possible to derive from that thread a statement that 'performance is a weak argument', and I do think it's bad to have a ratified php.net RFC that would make that statement as if it's an obvious truth.

That was probably on some other channel. As I said, I'm more than happy
to change that wording. =)

First, I do not prefer procedural programming. Personally I use OO a lot more than I use procedural. This is, however, completely besides the point - when designing and maintaining PHP, I put my personal preferences aside and try to think about what's right and consistent for the language. I think everyone who contributes should do the same.
Secondly, and very much related, suggesting "I'll do half the job, you can do the other half if you want" is very much the wrong approach IMHO. When introducing a new feature, we should strive to make it consistent across the board, catering to the wide range of users in our community, and not half baked according to the individual preferences of the subsets of the language one likes.
Thirdly, there's nothing inherently confusing about procedural APIs, or inherently clear about OO APIs. Yes, some of our legacy APIs are a mess, and it's a tough problem to tackle - but this has nothing to do with not wanting to introduce a procedural API for creating a UUID. The procedural/OO duality is not at all what people complain about when griping about PHP's API mess.
Last, yes, the rationale is indeed true for most additions to the language. The 2/3 barrier, as is explained in the Voting RFC (wiki.php.net/rfc/voting), has a rationale - the rationale being that unlike changes in apps or frameworks, changes to the language have an immense cost of reversal or incompatible alteration. Adding a top level object that's four letters long falls squarely within that definition - unlike, say, deciding when to release version X, or whether to call version Y "8.0" or "10.0". Looking at it from the other end - fast forward into 2021 a world where the current UUID proposal is accepted as-is, would we feel comfortable deprecating it with 50%+1 majority? If the answer's no, introducing it shouldn't be at 50%+1 either.

Zeev

I'm not going to propose a procedural API, because I truly believe that
it is the wrong abstraction for the problem. You, or anyone else with
the required Karma, can however propose a procedural API in a separate
RFC. I cannot do anything against that, and that is good and fine.
However, there is nothing that requires that I do that if I believe that
it is wrong.

A UUID is not a string, it is a 128 bit integer as defined in RFC 4112.
The string forms are meant for human readability, and serialization
only, not for dealing with them in a program. The first question that we
would need to answer would be then, what should uuid_vx_create return?
The binary form? The hex form? The string form? No clue to be honest.
Let's say we return the string form, because it is immediately readable
for anyone if printed.

How do I get the hex version of it?
Dedicated function again?

How do I get the binary version of it?
Dedicated function again?

Or maybe require people to use Composer, and search for a package on
their own?

Then again, it's totally simple. str_replace('-', '', $uuid) and you
have your hex version, now just add a hex2bin($hex) to that result,
and you're good to go.

Should we add that to the documentation?
Should we keep it a secret, and everybody needs to learn that on their own?

The latter is how it is done in C. A low-level language. Is PHP a
low-level language? I do not think so.

Another issue with the whole thing is with passing that UUID around.
People have to validate the string everywhere. Hence, we need a
uuid_parse or uuid_is_valid function.
Or should we again recommend Composer?

Then again, is Composer part of PHP?

I hope you're still with me. What I want to say is, that a procedural
approach comes with more questions than answers. A class can provide all
of this at once. People can decide what they want, binary, hex, or
string. We do not have to make that decision for them!

The proposed UUID class is smaller than the one in Java, Rust, Python,
... I made sure of that. I made sure that it has the least impact, as
well as the least complexity possible. While still providing the ability
to accommodate almost all needs. Doing exactly the same with a
procedural API that covers all the same use-cases would be much harder.

This might have to do with personal preference as well. However, I think
that you can only design something good in the way you prefer it. I do
not believe that people who never create procedural APIs are good at it.
They lack the knowledge in doing so. The same is true for designing a
purely functional API, I would not be good at it.

Hence, me proposing a pure procedural API might lead to a bad API.

I would like to add that PHP not only historically has bad APIs. We just
added the Sodium extension which has a horrible and confusing API as
well. I complained about this, its still being merged. There are already
thread popping up on Reddit about it ... it was added a few days ago.
That is sad, that makes me sad, ... I understand now why the PHP-FIG was
initiated, those people probably had comparable issues with PHP.

I joined internals because I want to help, I want to help with getting
in stuff that is actually useful for all web developers out there. A
dedicated UUID structure is one such small thing. A UUID string is not,
because it creates more problems than it solves. Probably spawning a PSR
for UUIDs, with an interface and two hundred implementations, where the
one is more over-engineered than the other.

I say let us fix this for once, and be done with it.

I gladly stop the vote, to ensure that the UUID topic is not blocked for
6 months. I will not provide a procedural API, because of the points
made. However, anyone is free to pick my code and provide one. Anyone is
free to propose the PECL version, which is already procedural (well, it
works only on Linux).

I'm, however, open to change the API to accommodate all valid points
raised; like Nikic did and does on GitHub. I actually already addressed
many issues based on his and the feedback of others on GitHub.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Fleshgrinder — view source

unread

I'm sorry if my replies sound pissed. I'm generally not good at being
diplomatic in writing or talking, and currently under a lot of stress in
real life (which is of course not the problem of you guys).

Please bare with me, I honor all constructive feedback I receive, truly!

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Sammy Kaye Powers — view source

unread

Richard wrote:
Maybe I should stop the vote. The discussion is happening now instead of
before when I asked for it.

I'm +1 for this because I'd love to see UUID's get added to PHP 7.3! :)

Thanks,
Sammy Kaye Powers
sammyk.me

6 years ago by Dan Ackroyd — view source

unread

Maybe I should stop the vote. The discussion is happening now instead of
before when I asked for it. We'll have to wait for at least six months
for another vote if this is a no, due to the rules.

That would be fine and appropriate. The RFC targets 7.3. Having a
discussion and vote in March gives plenty of time for getting it into
7.3

Cancelling a vote just to avoid an RFC being rejected is (imo) playing
slightly fast and loose with the rules.

cheers
Dan
Ack

6 years ago by Arvids Godjuks — view source

unread

I'd seriously start considering to start doing PHP code for things like
these, so they are not bogged down by the fact that they are in C and there
is 0.5 devs interested in supporting it.

Maybe I should stop the vote. The discussion is happening now instead of
before when I asked for it. We'll have to wait for at least six months
for another vote if this is a no, due to the rules.

That would be fine and appropriate. The RFC targets 7.3. Having a
discussion and vote in March gives plenty of time for getting it into
7.3

Cancelling a vote just to avoid an RFC being rejected is (imo) playing
slightly fast and loose with the rules.

cheers
Dan
Ack

6 years ago by Stanislav Malyshev — view source

unread

Hi!

That would be fine and appropriate. The RFC targets 7.3. Having a
discussion and vote in March gives plenty of time for getting it into
7.3

Cancelling a vote just to avoid an RFC being rejected is (imo) playing
slightly fast and loose with the rules.

I agree. I think the RFC itself is pretty clear. Some people agree with
the way it goes, some do not. If the latter are in majority, we should
let the vote finish, state the result as it is and then modify the RFC
(if the author or anybody else wishes, of course) according to it to
make it more acceptable, and then make another vote with the new
proposal. At least to me, it looks like most people (me included) agree
with the idea of having uuid implementation, but disagree with the
specifics of the RFC. So a modified one could have better support, but
there's no reason to not conclude the vote on the current one.

BTW, the RFC text does not have vote end date, please add it.

--
Stas Malyshev
smalyshev@gmail.com

6 years ago by Fleshgrinder — view source

unread

BTW, the RFC text does not have vote end date, please add it.

Done, had to move that to Wednesday, because I won't have Internet
access until then. Closing it today would mean that the min of 2 weeks
voting would not be achieved.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Zeev Suraski — view source

unread

Richard,

The minimal voting period is actually just one week, so as far as the Voting RFC requirements are concerned, you can close it right now. If you want to stick to the Sep 16 deadline you announced at the beginning of the vote, someone else can close the poll, Sep 16 is just hours away. Respectfully, it doesn't make sense to prolong it just because you don't have Internet access (plus, it's easy enough to work with wiki.php.net on 3G/mobile, from experience...)

Zeev

-----Original Message-----
From: Fleshgrinder [mailto:php@fleshgrinder.com]
Sent: Friday, September 15, 2017 7:00 PM
To: Stanislav Malyshev smalyshev@gmail.com; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

BTW, the RFC text does not have vote end date, please add it.

Done, had to move that to Wednesday, because I won't have Internet access until then. Closing it today would mean that the min of 2 weeks voting would not be achieved.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Niklas Keller — view source

unread

Richard,

The minimal voting period is actually just one week, so as far as the
Voting RFC requirements are concerned, you can close it right now. If you
want to stick to the Sep 16 deadline you announced at the beginning of the
vote, someone else can close the poll, Sep 16 is just hours away.
Respectfully, it doesn't make sense to prolong it just because you don't
have Internet access (plus, it's easy enough to work with wiki.php.net on
3G/mobile, from experience...)

Zeev

If it's closed a few days later, it doesn't matter either.

Regards, Niklas

6 years ago by Andi Gutmans — view source

unread

Why would we not just add this under Spl? Feels like an appropriate place to put standard methods.
I would definitely not make functionality like this a top level class/namespace both for BC reasons and it is a minor capability that fits in well into a standard library context.

Get Outlook for iOShttps://aka.ms/o0ukef

From: Fleshgrinder php@fleshgrinder.com
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

I just voted 'no', and I'd like to quickly explain why:

I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.

I think a renewed discussion, beyond the two days of discussion 3+ months ago would be useful, as beyond that basic (yet important) point - I have thoughts about a bunch of things in the RFC, and honestly didn't even notice the brief discussion months ago (if there was another one then my apologies, I couldn't find it).

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

I think that a function that returns a string (a-la uuid_v4_create() Nikita proposed) would make perfect sense. Forcing the use of classes/objects in such a case - where there's little to no added value, is wrong and uncommon (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

The section dealing with backwards incompatible changes, states:
"Both UUID and UUIDParseException are now globally defined classes, which might collide with user defined classes of the same name in the global namespace. However, the risk of the introduction of them is considered to be very low, since the global namespace should not be used by PHP users."
... erroneously assumes that all code in PHP utilizes namespaces. IMHO this is a projection of a particular coding style onto the entire PHP userbase. We haven't deprecated at any point the ability to place user classes in the global namespace, we haven't even as much as said at any point we might be considering it - and I don't think we should, either. My gut feel, backed by a quick Google search refutes the assumption that the risk of introducing - at least the UUID class - is very low. Not that I have a better suggestion (other than not introducing a class at all) - but I think the text there should be changed as it does not reflect reality.

The very same would be true for any function that is being introduced in
the global namespace. I had an RFC for namespaces prepared and ready for
vote; incl. a namespaced UUID implementation. However, the feedback on
it was so extremely negative and hostile that I decided to withdraw it.

If I voted yes, it would also mean I agree with a statement such as "One could argue that it is faster (C implementation), which it probably is, but this is a weak argument". I disagree it's a weak argument - and I do think that for basic building blocks of the language, performance absolutely matters. If we manage to get JIT out the door and the performance differences become negligible - then I see a lot of value in moving some of our core value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

Given we seem to agree this is a basic building block of the language (as it is in other languages), I do think it should be a 2/3 majority vote and not a 50%+1 one. Taking the "is this something we can easily change w/o affecting BC" test, this clearly gets a 'no'.

Actually we can. Both classes are final and users cannot extend them.
The only thing we cannot do is rename the stuff that's already in them.
This is one of the reasons why I kept the provided functionality to a
bare minimum.

To summarize - I'm strongly in favor of fixing this issue in PHP, but at the same time against the proposed solution. I'd vote in favor of something along the lines of uuid_v4_create() in a heartbeat.

$bin = \UUID::v4()->toBinary();
$hex = \UUID::v4()->toHex();
$str = \UUID::v4()->toString();

You can already use it like you want, with greater possibilities and
freedom. Incl. auto-completion with your favorite editor to explore your
possibilities, and type-safety everywhere as an opt-in.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Marco Pivetta — view source

unread

Why would it go under Spl? Spl is already bloated with loads of unrelated
classes with no real logical grouping.

Why would we not just add this under Spl? Feels like an appropriate place
to put standard methods.
I would definitely not make functionality like this a top level
class/namespace both for BC reasons and it is a minor capability that fits
in well into a standard library context.

Get Outlook for iOShttps://aka.ms/o0ukef

From: Fleshgrinder php@fleshgrinder.com
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

I just voted 'no', and I'd like to quickly explain why:

I agree with the premise of the RFC, that we should have something
better than uniqid() built into the language.

I think a renewed discussion, beyond the two days of discussion 3+
months ago would be useful, as beyond that basic (yet important) point - I
have thoughts about a bunch of things in the RFC, and honestly didn't even
notice the brief discussion months ago (if there was another one then my
apologies, I couldn't find it).

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

I think that a function that returns a string (a-la uuid_v4_create()
Nikita proposed) would make perfect sense. Forcing the use of
classes/objects in such a case - where there's little to no added value, is
wrong and uncommon (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

The section dealing with backwards incompatible changes, states:
"Both UUID and UUIDParseException are now globally defined classes, which
might collide with user defined classes of the same name in the global
namespace. However, the risk of the introduction of them is considered to
be very low, since the global namespace should not be used by PHP users."
... erroneously assumes that all code in PHP utilizes namespaces. IMHO
this is a projection of a particular coding style onto the entire PHP
userbase. We haven't deprecated at any point the ability to place user
classes in the global namespace, we haven't even as much as said at any
point we might be considering it - and I don't think we should, either.
My gut feel, backed by a quick Google search refutes the assumption that
the risk of introducing - at least the UUID class - is very low. Not that
I have a better suggestion (other than not introducing a class at all) -
but I think the text there should be changed as it does not reflect reality.

The very same would be true for any function that is being introduced in
the global namespace. I had an RFC for namespaces prepared and ready for
vote; incl. a namespaced UUID implementation. However, the feedback on
it was so extremely negative and hostile that I decided to withdraw it.

If I voted yes, it would also mean I agree with a statement such as
"One could argue that it is faster (C implementation), which it probably
is, but this is a weak argument". I disagree it's a weak argument - and I
do think that for basic building blocks of the language, performance
absolutely matters. If we manage to get JIT out the door and the
performance differences become negligible - then I see a lot of value in
moving some of our core value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

Given we seem to agree this is a basic building block of the language
(as it is in other languages), I do think it should be a 2/3 majority vote
and not a 50%+1 one. Taking the "is this something we can easily change
w/o affecting BC" test, this clearly gets a 'no'.

Actually we can. Both classes are final and users cannot extend them.
The only thing we cannot do is rename the stuff that's already in them.
This is one of the reasons why I kept the provided functionality to a
bare minimum.

To summarize - I'm strongly in favor of fixing this issue in PHP, but at
the same time against the proposed solution. I'd vote in favor of
something along the lines of uuid_v4_create() in a heartbeat.

$bin = \UUID::v4()->toBinary();
$hex = \UUID::v4()->toHex();
$str = \UUID::v4()->toString();

You can already use it like you want, with greater possibilities and
freedom. Incl. auto-completion with your favorite editor to explore your
possibilities, and type-safety everywhere as an opt-in.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Andi Gutmans — view source

unread

If we say it is a ubiquitous need and Spl stands for "Standard PHP Library" and namespace is already taken then why not? Better than breaking BC on a global UUID...

Get Outlook for iOShttps://aka.ms/o0ukef

From: Marco Pivetta ocramius@gmail.com
Sent: Sunday, September 3, 2017 10:30:53 AM
To: Andi Gutmans
Cc: PHP Internals List; Zeev Suraski
Subject: Re: [PHP-DEV] [VOTE] UUID

Why would it go under Spl? Spl is already bloated with loads of unrelated classes with no real logical grouping.

Why would we not just add this under Spl? Feels like an appropriate place to put standard methods.
I would definitely not make functionality like this a top level class/namespace both for BC reasons and it is a minor capability that fits in well into a standard library context.

Get Outlook for iOShttps://aka.ms/o0ukef

From: Fleshgrinder <php@fleshgrinder.com mailto:php@fleshgrinder.com>
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net mailto:internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

I just voted 'no', and I'd like to quickly explain why:

I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.

I think a renewed discussion, beyond the two days of discussion 3+ months ago would be useful, as beyond that basic (yet important) point - I have thoughts about a bunch of things in the RFC, and honestly didn't even notice the brief discussion months ago (if there was another one then my apologies, I couldn't find it).

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

I think that a function that returns a string (a-la uuid_v4_create() Nikita proposed) would make perfect sense. Forcing the use of classes/objects in such a case - where there's little to no added value, is wrong and uncommon (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

The section dealing with backwards incompatible changes, states:
"Both UUID and UUIDParseException are now globally defined classes, which might collide with user defined classes of the same name in the global namespace. However, the risk of the introduction of them is considered to be very low, since the global namespace should not be used by PHP users."
... erroneously assumes that all code in PHP utilizes namespaces. IMHO this is a projection of a particular coding style onto the entire PHP userbase. We haven't deprecated at any point the ability to place user classes in the global namespace, we haven't even as much as said at any point we might be considering it - and I don't think we should, either. My gut feel, backed by a quick Google search refutes the assumption that the risk of introducing - at least the UUID class - is very low. Not that I have a better suggestion (other than not introducing a class at all) - but I think the text there should be changed as it does not reflect reality.

The very same would be true for any function that is being introduced in
the global namespace. I had an RFC for namespaces prepared and ready for
vote; incl. a namespaced UUID implementation. However, the feedback on
it was so extremely negative and hostile that I decided to withdraw it.

If I voted yes, it would also mean I agree with a statement such as "One could argue that it is faster (C implementation), which it probably is, but this is a weak argument". I disagree it's a weak argument - and I do think that for basic building blocks of the language, performance absolutely matters. If we manage to get JIT out the door and the performance differences become negligible - then I see a lot of value in moving some of our core value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

Given we seem to agree this is a basic building block of the language (as it is in other languages), I do think it should be a 2/3 majority vote and not a 50%+1 one. Taking the "is this something we can easily change w/o affecting BC" test, this clearly gets a 'no'.

Actually we can. Both classes are final and users cannot extend them.
The only thing we cannot do is rename the stuff that's already in them.
This is one of the reasons why I kept the provided functionality to a
bare minimum.

To summarize - I'm strongly in favor of fixing this issue in PHP, but at the same time against the proposed solution. I'd vote in favor of something along the lines of uuid_v4_create() in a heartbeat.

$bin = \UUID::v4()->toBinary();
$hex = \UUID::v4()->toHex();
$str = \UUID::v4()->toString();

You can already use it like you want, with greater possibilities and
freedom. Incl. auto-completion with your favorite editor to explore your
possibilities, and type-safety everywhere as an opt-in.

--
Richard "Fleshgrinder" Fussenegger

6 years ago by Niklas Keller — view source

unread

If we say it is a ubiquitous need and Spl stands for "Standard PHP
Library" and namespace is already taken then why not? Better than breaking
BC on a global UUID...

It doesn't really matter where it ends up, but which namespace is already
taken and how does moving things to Spl change anything BC related?

Regards, Niklas

6 years ago by Arvids Godjuks — view source

unread

2017-09-05 12:24 GMT+03:00 Stephen Reay stephen@bobs-bits.com:

That way the API and
features can be stabilized.

Hi Arvids,

This is exactly why I (and possibly others) are in favour of this being
implemented as a few functions - the object side of things can then be left
to a user land implementation, which is much easier to update and refine.

Cheers

Stephen

I would agree if this was something that was in flux or didn't have a set
in stone standard that is universal across languages, platforms and all
kinds of other software (databases come to mind, some have full-blown
first-class citizen support for them, MySQL is also on the path to
introducing them as field type last I heard too).

This is about making a UUID a first-class citizen and having it universally
available going forward, be able to use it as a type hint, same as
DateTimeInterface is used these days (a lot, actually).

Just provide a procedural-style API together with the OOP one. I recon the
OOP one is gonna be used way more though - every userland implementation I
ever saw used an OOP approach.

Or just start packaging PHP code that is shipped with the interpreter: Ship
the Ramsey\Uuid with 7.3 or some 7.2.x release. That one seems the defacto
standard everyone uses, and it is used in my current project too :) Would
be a perfect segway for the discussion we had on the list a few months ago
about doing parts of the packaged modules in PHP itself.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius