rfc:uuid
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:uuid [2017/05/25 15:07] – Added paragraph about Doxygen fleshgrinder | rfc:uuid [2017/08/29 07:33] – Fixed broken links fleshgrinder | ||
---|---|---|---|
Line 40: | Line 40: | ||
==== Why C? ==== | ==== Why C? ==== | ||
- | There is no reason why this should be implemented in C. One could argue that it is faster, which it probably is, but this is a weak argument. This RFC would propose the inclusion of UUIDs implemented in PHP if shipping of PHP code as part of the standard module of PHP would be possible. | + | There is no reason why this should be implemented in C. One could argue that it is faster, which it probably is, but this is a weak argument. This RFC would propose the inclusion of UUIDs implemented in PHP if shipping of PHP code as part of the standard module of PHP would be possible. However, there is a C API included that allows other PHP modules to utilize UUIDs. |
=== Why not PECL UUID? === | === Why not PECL UUID? === | ||
Line 46: | Line 46: | ||
==== Why a Class? ==== | ==== Why a Class? ==== | ||
- | UUIDs are basically random data. There is no way for an application to distinguish between a string of 16 bytes (since strings in PHP are random bytes too) and a UUID. This problem can be minimized through the implementation of UUIDs as a class. The code that constraints a type to a UUID has the guarantee that the string is of exactly 16 bytes. The developer that constraints a type to a UUID has the guarantee that the other developer passing a value at least had to have a look at the UUID class. Of course, there is nothing that prevent | + | UUIDs are basically random data. There is no way for an application to distinguish between a string of 16 bytes (since strings in PHP are random bytes too) and a UUID. This problem can be minimized through the implementation of UUIDs as a class. The code that constraints a type to a UUID has the guarantee that the string is of exactly 16 bytes. The developer that constraints a type to a UUID has the guarantee that the other developer passing a value at least had to have a look at the UUID class. Of course, there is nothing that prevents |
==== Implementation ==== | ==== Implementation ==== | ||
The implementation consists of two new final classes in the global namespace. Supported generation algorithms are version 3, 4, and 5. Version 3 is provided for backwards compatibility with existing UUID implementations, | The implementation consists of two new final classes in the global namespace. Supported generation algorithms are version 3, 4, and 5. Version 3 is provided for backwards compatibility with existing UUID implementations, | ||
- | < | + | < |
<code php> | <code php> | ||
Line 109: | Line 109: | ||
</ | </ | ||
- | < | + | < |
<code php> | <code php> | ||
Line 169: | Line 169: | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | Both '' | + | Both '' |
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
Line 191: | Line 191: | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
- | ==== Argument Parsing ==== | + | None |
- | The provided implementation makes use of the latest features that were added to PHP 7 and PHP 7.1, namely return type constraints. It is customary for internal PHP routines to verify that the number of parameters that were passed match exactly the signature of the routine, and to emit a warning if that count mismatches followed by returning null. The problem with this approach in combination with return type constraints is that a '' | + | |
- | + | ||
- | Making all return type constraints nullable (as would be possible since PHP 7.1) is a very bad idea, since it would break the promise of the routine, and every caller is required to account for null. Even if they pass the correct amount of arguments, since it becomes unclear just from looking at the signature in which situations null is actually returned. This completely defeats the purpose of a return type constraint. | + | |
- | + | ||
- | Another possible approach would be to simply ignore the parameters that were passed, not validating them at all. The problem with this approach is that it is different to how all the other internal PHP routines work. Nikita Popov said that doing this would require a global decision for all of PHP’s internal code. | + | |
- | + | ||
- | The last possible approach, and the one that is currently implemented, | + | |
- | + | ||
- | ==== Namespace ==== | + | |
- | The discussion about namespace in PHP core is on ongoing dispute. This highly self-contained component could easily be provided from an internal namespace and thus lay the grounds for other things to come. This would require additional discussion, but possible namespaces in alphabetical order are: | + | |
- | + | ||
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | * '' | + | |
- | + | ||
- | ==== Final Class ==== | + | |
- | The '' | + | |
- | + | ||
- | ==== Doxygen Documentation ==== | + | |
- | The provided implementation uses [[http:// | + | |
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
Line 220: | Line 197: | ||
===== Future Scope ===== | ===== Future Scope ===== | ||
- | * Deprecate and then remove '' | + | * [[https://wiki.php.net/rfc/ |
- | * Addition of a '' | + | * Addition of a '' |
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
Line 237: | Line 214: | ||
===== References ===== | ===== References ===== | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
* [[http:// | * [[http:// | ||
* [[https:// | * [[https:// | ||
- | * [[https://tools.ietf.org/html/ | + | * [[https://twitter.com/AmbassadorAwsum/status/868097123627171842|Twitter discussion]] |
- | * [[https:// | + | |
===== Rejected Features ===== | ===== Rejected Features ===== | ||
None so far. | None so far. |
rfc/uuid.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1