| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| rfc:var_type [2016/07/04 18:50] – Removed performance section, benchmarks show that this is not true is normal scripts fleshgrinder | rfc:var_type [2017/09/22 13:28] (current) – external edit 127.0.0.1 |
|---|
| ====== PHP RFC: var_type ====== | ====== PHP RFC: var_type ====== |
| * Version: 0.3 | * Version: 1.0 |
| * Date: 2016-06-25 | * Date: 2016-06-25 |
| * Author: Richard Fussenegger <php@fleshgrinder.com> | * Author: Richard Fussenegger <php@fleshgrinder.com> |
| * Status: Under Discussion | * Status: Declined |
| * First Published at: https://wiki.php.net/rfc/var_type | * First Published at: https://wiki.php.net/rfc/var_type |
| |
| ==== Prefix Choice ==== | ==== Prefix Choice ==== |
| The function prefix ''var_'' was chosen on purpose because another possibly more suitable prefix like ''val_'' or ''value_'' would introduce a new prefix to the PHP ecosystem. It is true that this function can be used with the return value of functions too as well as with literal values, however, exactly the same argument is true for ''var_dump()'' and ''var_export()''. The goal of this RFC is it to improve consistency and not to introduce more inconsistencies. The assumption that the type of a variable is the type of its current value is furthermore logical and comprehensible. Last but not least, this function is probably not going to be used with literal values at all, since the type of them is definitely known to the developer writing the code. It might be used for return values of functions but the use cases seem very, very limited without storing the actual value to a variable first. | The function prefix ''var_'' was chosen on purpose because another possibly more suitable prefix like ''val_'' or ''value_'' would introduce a new prefix to the PHP ecosystem. It is true that this function can be used with the return value of functions too as well as with literal values, however, exactly the same argument is true for ''var_dump()'' and ''var_export()''. The goal of this RFC is it to improve consistency and not to introduce more inconsistencies. The assumption that the type of a variable is the type of its current value is furthermore logical and comprehensible. Last but not least, this function is probably not going to be used with literal values at all, since the type of them is definitely known to the developer writing the code. It might be used for return values of functions but the use cases seem very, very limited without storing the actual value to a variable first. |
| | |
| | ==== Performance ==== |
| | The new ''var_type()'' function is faster if full utilization of interned strings is possible because it can utilize globally cached strings for the type names. It makes no sense to optimize the old ''gettype()'' function in the same manner since caching of the old type names makes no sense, they are not useful in any other context and would occupy additional memory globally for a single function. |
| | |
| | Note well that the various ''is_*'' functions are still faster and ''var_type()'' is not meant to compete with them, again, they serve different purposes. |
| |
| ==== Phasing Out of gettype ==== | ==== Phasing Out of gettype ==== |
| This RFC does **not** propose a deprecation of ''gettype()'' in PHP 7.x because it is a widely used function and there are currently no plans on how to deal with its counterpart ''settype()''. However, a //soft deprecation// of ''gettype()'' is recommended, this means that the documentation page of ''gettype()'' will be updated with an informational box that recommends the usage of ''var_type()'' in favor of ''gettype()'' and any references to ''gettype()'' in the manual should be replaced with ''var_type()''. | This RFC does **not** propose a deprecation of ''gettype()'' in PHP 7.x because it is a widely used function and there are currently no plans on how to deal with its counterpart ''settype()''. Even if there would be plans, a true deprecation of ''gettype()'' would be a bad idea in any context because libraries and applications need the ability to offer their users an upgrade path. This path would be very bumpy if PHP is emitting deprecation errors upon the usage of ''gettype()''. Such a library or application fallback might be necessary in situations like we see [[https://github.com/doctrine/annotations/blob/master/lib/Doctrine/Common/Annotations/DocParser.php#L756-L789|here it in Doctrine annotations]]. The solution for such situations would be something like: |
| | |
| | <code php> |
| | if ((var_type($var) === $user_type || gettype($var) === $user_type) || $var instanceof $user_type) { |
| | // ... |
| | } |
| | </code> |
| | |
| | However, a //soft deprecation// of ''gettype()'' is recommended, this means that the documentation page of ''gettype()'' will be updated with an informational box that recommends the usage of ''var_type()'' in favor of ''gettype()'' and any references to ''gettype()'' in the manual should be replaced with ''var_type()''. |
| | |
| | It is further recommended to tackle the deprecation and a possible removal of the ''gettype()'' function together with a proper solution for ''settype()'' in a future major release. A possible approach could be to emit an ''E_STRICT'' in PHP 8, deprecate in PHP 9, and remove in PHP 10; or any other combination that results in a long adoption period. |
| |
| ===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== |
| ===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== |
| This RFC will have two polls, one for the introduction of the ''var_type()'' function and one for the new ''TYPE_*'' constants in userland. Both require a 50%+1 majority to be accepted as they do not change the language's syntax. | This RFC will have two polls, one for the introduction of the ''var_type()'' function and one for the new ''TYPE_*'' constants in userland. Both require a 50%+1 majority to be accepted as they do not change the language's syntax. |
| | |
| | Voting opened on 2016-07-08 and will end on 2016-07-22 for both votes. |
| | |
| | == Function == |
| | <doodle title="Accept var_type function?" auth="fleshgrinder" voteType="single" closed="false"> |
| | * Yes |
| | * No |
| | </doodle> |
| | |
| | == Constants == |
| | <doodle title="Accept type constants?" auth="fleshgrinder" voteType="single" closed="true"> |
| | * Yes |
| | * No |
| | </doodle> |
| |
| ===== Patches and Tests ===== | ===== Patches and Tests ===== |
| The [[https://github.com/php/php-src/pull/1935|GitHub Pull Request #1935]] contains the implementation as well as tests for the new function. The changes in the PR are considered final, however, a thorough code review would be much appreciated and might result in minor changes. | The [[https://github.com/php/php-src/pull/1935|GitHub Pull Request #1935]] contains the implementation as well as tests for the new function. The changes in the PR are considered final, however, a thorough code review would be much appreciated and might result in minor changes. |
| |
| ===== Implementation ===== | |
| - Merged to Version: //?// | |
| - Git Commits: //?// | |
| - PHP Manual: https://secure.php.net/var_type | |
| |
| ===== References ===== | ===== References ===== |