Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [VOTE] UUID

Posted by Fleshgrinder 
Fleshgrinder
[PHP-DEV] [VOTE] UUID
September 02, 2017 09:10AM
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
Niklas Keller
Re: [PHP-DEV] [VOTE] UUID
September 02, 2017 09:40AM
>
> 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
Fleshgrinder
Re: [PHP-DEV] [VOTE] UUID
September 02, 2017 09:40AM
On 9/2/2017 9:32 AM, Niklas Keller wrote:
>>
>> 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
Zeev Suraski
RE: [PHP-DEV] [VOTE] UUID
September 02, 2017 12:20PM
I just voted 'no', and I'd like to quickly explain why:

0. I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.
1. 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).
2. 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.
3. 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.
4. 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.
5. 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:[email protected]]
Sent: שבת 02 ספטמבר 2017 10:02
To: php-internals <[email protected]>
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
Fleshgrinder
Re: [PHP-DEV] [VOTE] UUID
September 02, 2017 12:50PM
Hey Zeev :)

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> I just voted 'no', and I'd like to quickly explain why:
>
> 0. I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.
> 1. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 2. 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?

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 3. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 4. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 5. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 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
Zeev Suraski
Re: [PHP-DEV] [VOTE] UUID
September 02, 2017 02:30PM
> On 2 Sep 2017, at 13:43, Fleshgrinder <[email protected]> wrote:

> On 9/2/2017 12:14 PM, Zeev Suraski wrote:
>> I just voted 'no', and I'd like to quickly explain why:
>>
>> 0. I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.
>> 1. 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.

>
>> On 9/2/2017 12:14 PM, Zeev Suraski wrote:
>> 2. 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.

>
>> On 9/2/2017 12:14 PM, Zeev Suraski wrote:
>> 3. 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.
>
>
>> On 9/2/2017 12:14 PM, Zeev Suraski wrote:
>> 4. 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.
>
>> On 9/2/2017 12:14 PM, Zeev Suraski wrote:
>> 5. 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [VOTE] UUID
September 03, 2017 09:20AM
On 9/2/2017 2:26 PM, Zeev Suraski wrote:
>
>> On 2 Sep 2017, at 13:43, Fleshgrinder <[email protected]> wrote:
>> 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.

On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> 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

On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> 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.

On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> 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
Andi Gutmans
Re: [PHP-DEV] [VOTE] UUID
September 03, 2017 07:10PM
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 <[email protected]>
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> I just voted 'no', and I'd like to quickly explain why:
>
> 0. I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.
> 1. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 2. 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?

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 3. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 4. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 5. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 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
Marco Pivetta
Re: [PHP-DEV] [VOTE] UUID
September 03, 2017 07:40PM
Why would it go under Spl? Spl is already bloated with loads of unrelated
classes with no real logical grouping.

On 3 Sep 2017 19:03, "Andi Gutmans" <[email protected]> wrote:

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 <[email protected]>
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> I just voted 'no', and I'd like to quickly explain why:
>
> 0. I agree with the premise of the RFC, that we should have something
better than uniqid() built into the language.
> 1. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 2. 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?

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 3. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 4. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 5. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 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
Christoph M. Becker
[PHP-DEV] Re: [VOTE] UUID
September 04, 2017 12:30AM
On 02.09.2017 at 09:01, Fleshgrinder wrote:

> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans
Re: [PHP-DEV] [VOTE] UUID
September 04, 2017 07:30AM
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 <[email protected]>
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.

On 3 Sep 2017 19:03, "Andi Gutmans" <[email protected]<mailto:[email protected]>> wrote:
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 <[email protected]<mailto:[email protected]>>
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net<mailto:[email protected]>
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> I just voted 'no', and I'd like to quickly explain why:
>
> 0. I agree with the premise of the RFC, that we should have something better than uniqid() built into the language.
> 1. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 2. 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?

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 3. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 4. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 5. 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.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 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
Niklas Keller
Re: [PHP-DEV] [VOTE] UUID
September 04, 2017 08:30AM
>
> 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
Zeev Suraski
RE: [PHP-DEV] [VOTE] UUID
September 04, 2017 11:10AM
> -----Original Message-----
> From: Fleshgrinder [mailto:[email protected]]
> Sent: Sunday, September 3, 2017 10:17 AM
> To: Zeev Suraski <[email protected]>; internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE] UUID
>
> On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> >
> >> On 2 Sep 2017, at 13:43, Fleshgrinder <[email protected]> wrote:
> >> 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."

> On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> > 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
Marco Pivetta
RE: [PHP-DEV] [VOTE] UUID
September 04, 2017 11:20AM
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.


On 4 Sep 2017 11:04, "Zeev Suraski" <[email protected]> wrote:

> > -----Original Message-----
> > From: Fleshgrinder [mailto:[email protected]]
> > Sent: Sunday, September 3, 2017 10:17 AM
> > To: Zeev Suraski <[email protected]>; internals@lists.php.net
> > Subject: Re: [PHP-DEV] [VOTE] UUID
> >
> > On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> > >
> > >> On 2 Sep 2017, at 13:43, Fleshgrinder <[email protected]> wrote:
> > >> 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."
>
> > On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> > > 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
>
>
>
Remi Collet
Re: [PHP-DEV] [VOTE] UUID
September 04, 2017 04:00PM
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
Sammy Kaye Powers
Re: [PHP-DEV] [VOTE] UUID
September 04, 2017 06:10PM
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


On Sat, Sep 2, 2017 at 2:01 AM, Fleshgrinder <[email protected]> wrote:
> 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
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Arvids Godjuks
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 09:40AM
2017-09-04 19:03 GMT+03:00 Sammy Kaye Powers <[email protected]>:

> 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
Arvids Godjuks
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 12:00PM
2017-09-05 12:24 GMT+03:00 Stephen Reay <[email protected]>:

>
> On 5 Sep 2017, at 14:32, Arvids Godjuks <[email protected]> wrote:
>
> 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
Stephen Reay
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 01:40PM
> On 5 Sep 2017, at 14:32, Arvids Godjuks <[email protected]> wrote:
>
> 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
Andreas Heigl
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 07:10PM
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:[email protected] N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Fleshgrinder
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 07:30PM
On 9/4/2017 11:04 AM, Zeev Suraski wrote:
> 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.

On 9/4/2017 11:04 AM, Zeev Suraski wrote:
> 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.

On 9/4/2017 11:04 AM, Zeev Suraski wrote:
> 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.

On 9/4/2017 11:04 AM, Zeev Suraski wrote:
> 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. =)

On 9/4/2017 11:04 AM, Zeev Suraski wrote:
> 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
Fleshgrinder
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 07:40PM
On 9/5/2017 7:01 PM, Andreas Heigl wrote:
> 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
Fleshgrinder
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 07:50PM
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
Andreas Heigl
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 09:40PM
Hey Richard

Am 05.09.17 um 19:29 schrieb Fleshgrinder:
> On 9/5/2017 7:01 PM, Andreas Heigl wrote:
>> 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:[email protected] N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Fleshgrinder
Re: [PHP-DEV] [VOTE] UUID
September 05, 2017 10:10PM
On 9/5/2017 9:32 PM, Andreas Heigl wrote:
> 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
Sammy Kaye Powers
Re: [PHP-DEV] [VOTE] UUID
September 06, 2017 01:10AM
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] [VOTE] UUID
September 06, 2017 09:30AM
On Di., 5. Sep. 2017, 21:32 Andreas Heigl <[email protected]> wrote:

> Hey Richard
>
> Am 05.09.17 um 19:29 schrieb Fleshgrinder:
> > On 9/5/2017 7:01 PM, Andreas Heigl wrote:
> >> 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:[email protected] N 50°22'59.5" E 08°23'58" |
> | http://andreas.heigl.org http://hei.gl/wiFKy7 |
> +---------------------------------------------------------------------+
> | http://hei.gl/root-ca |
> +---------------------------------------------------------------------+
>
>
Dan Ackroyd
Re: [PHP-DEV] [VOTE] UUID
September 06, 2017 01:20PM
On 5 September 2017 at 18:24, Fleshgrinder <[email protected]> wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Arvids Godjuks
Re: [PHP-DEV] [VOTE] UUID
September 06, 2017 01:50PM
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.

On Wed, 6 Sep 2017, 14:09 Dan Ackroyd <[email protected]> wrote:

> On 5 September 2017 at 18:24, Fleshgrinder <[email protected]> wrote:
> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Stanislav Malyshev
Re: [PHP-DEV] [VOTE] UUID
September 06, 2017 10:00PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login