# [RFC] Reserving More Types in PHP 7 - Thread: https://externals.io/message/83254 - Original archive: https://news-web.php.net/php.internals/83254 - Started by Levi Morrison on 2015-02-20T01:35:27+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #83254 — Levi Morrison — 2015-02-20T01:35:27+00:00 URL: https://externals.io/message/83254#83254 Dear Internals, I would like to discuss a small RFC for reserving more types in PHP 7: https://wiki.php.net/rfc/reserve_more_types_in_php_7 Essentially it proposes to reserve: --- ## #83255 — Levi Morrison — 2015-02-20T01:36:19+00:00 URL: https://externals.io/message/83254#83255 · In reply to: #83254 Sorry: Apparently hit some hotkey for send. > Dear Internals, > > I would like to discuss a small RFC for reserving more types in PHP 7: > https://wiki.php.net/rfc/reserve_more_types_in_php_7 > > Essentially it proposes to reserve: int, integer bool, boolean true, false float, double string null It does not make them keywords; it only prevents them from being used in class, interface, trait and namespace names. --- ## #83261 — francois@php.net — 2015-02-20T04:01:05+00:00 URL: https://externals.io/message/83254#83261 · In reply to: #83255 Hi Levi, Just my opinion : Add 'resource', 'object', 'scalar', 'mixed', 'numeric' Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere) Not sure we'll use Boolean and integer but reserve also. Hope 'null', 'true', and 'false' can technically be used as type hints. If not, bad news, especially for null. Love 'int|false' as return type ! Regards François > -----Message d'origine----- > De : morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] De la part > de Levi Morrison > Envoyé : vendredi 20 février 2015 02:36 > À : internals > Objet : [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7 > > Sorry: Apparently hit some hotkey for send. > > > > […] > > int, integer > bool, boolean > true, false > float, double > string > null > > It does not make them keywords; it only prevents them from being used > in class, interface, trait and namespace names. --- ## #83262 — Sara Golemon — 2015-02-20T04:04:13+00:00 URL: https://externals.io/message/83254#83262 · In reply to: #83255 > I would like to discuss a small RFC for reserving more types in PHP 7: > https://wiki.php.net/rfc/reserve_more_types_in_php_7 > > Essentially it proposes to reserve: > > int, integer > bool, boolean > true, false > float, double > string > null > +1 -- I was planning to put this up today and got waylaid. > > Add 'resource', 'object', 'scalar', 'mixed', 'numeric' > > Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere) > > Hope 'null', 'true', and 'false' can technically be used as type hints. > If not, bad news, especially for null. Love 'int|false' as return type ! > If I were to change one thing, it'd be to add some metatypes (possibly as a separate vote): > I also agree with everything François said. Reserve these additional types (possibly in a separate vote, up to you). -Sara --- ## #83266 — Kalle Sommer Nielsen — 2015-02-20T06:13:17+00:00 URL: https://externals.io/message/83254#83266 · In reply to: #83255 2015-02-20 2:36 GMT+01:00 Levi Morrison : > int, integer > bool, boolean > true, false > float, double I guess we should add 'real' here as well, since we still have the (real) type cast and is_() type check for consistency: C:\dev\php-src>php -r "var_dump((real) 42, is_real(13.37));" float(42) bool(true) > string > null -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #83288 — Andrey Andreev — 2015-02-20T11:21:45+00:00 URL: https://externals.io/message/83254#83288 · In reply to: #83261 Hi, > Hi Levi, > > Just my opinion : > > Add 'resource', 'object', 'scalar', 'mixed', 'numeric' > > Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere) > > Not sure we'll use Boolean and integer but reserve also. > > Hope 'null', 'true', and 'false' can technically be used as type hints. If not, bad news, especially for null. Love 'int|false' as return type ! > I'd rather not reserve 'resource'. Such a hint may be useful in the short term, but there already are plans to turn the current resources into objects, and with the rise of REST lately it is also an obvious base class/interface/trait name. Agree on 'double' though ... if we want to discourage its usage, we might even think of deprecating it. Cheers, Andrey. --- ## #83315 — Levi Morrison — 2015-02-20T16:00:21+00:00 URL: https://externals.io/message/83254#83315 · In reply to: #83288 > > > […] If someone wants to reserve these I will leave them up to another RFC, as I suspect they are more controversial than what I have proposed. > > […] This is out of scope for this RFC, but if this RFC passes they would be reserved which means this *could* be done without BC breaks in the future. > I'd rather not reserve 'resource'. Such a hint may be useful in the > short term, but there already are plans to turn the current resources > into objects, and with the rise of REST lately it is also an obvious > base class/interface/trait name. > > Agree on 'double' though ... if we want to discourage its usage, we > might even think of deprecating it. While deprecating it might be a good course of action, it is out of scope of this RFC. I personally think that reserving it is a good way to discourage its use: simply reserve it and then don't use it for anything. If we decide not to use the aliases if we have scalar types and the aliases are reserved this would prevent users from making custom types from the aliases. In my opinion this a Good Thing. --- ## #83316 — Levi Morrison — 2015-02-20T16:06:19+00:00 URL: https://externals.io/message/83254#83316 · In reply to: #83266 > 2015-02-20 2:36 GMT+01:00 Levi Morrison : > > […] > > I guess we should add 'real' here as well, since we still have the > (real) type cast and is_() type check for consistency: > > C:\dev\php-src>php -r "var_dump((real) 42, is_real(13.37));" > float(42) > bool(true) How do others else feel about this? I am undecided at the moment. --- ## #83318 — Andrey Andreev — 2015-02-20T16:11:13+00:00 URL: https://externals.io/message/83254#83318 · In reply to: #83315 Hi, > > > […] > > While deprecating it might be a good course of action, it is out of > scope of this RFC. I personally think that reserving it is a good way > to discourage its use: simply reserve it and then don't use it for > anything. If we decide not to use the aliases if we have scalar types > and the aliases are reserved this would prevent users from making > custom types from the aliases. In my opinion this a Good Thing. Well, I meant to deprecate `is_double()`, is_real() and the corresponding explicit casts. I might be missing other places when they are used, not sure, but the point would be to stop using these names for scalar types at all, so that everybody can freely use them for class/trait/interface names ... I don't think anybody would do that only for pseudo-scalar hinting objects. So, while yes - that's outside of this RFC's scope, reserving them as keywords would be the opposite of what I had in mind. Cheers, Andrey. --- ## #83320 — Kingsquare.nl - Robin Speekenbrink — 2015-02-20T16:24:54+00:00 URL: https://externals.io/message/83254#83320 · In reply to: #83318 Hi, First of all I'd like to see this (clean) RFC formalized / ratified sooner rather than later. Just to chime in here from a user / framework developer perspective in regards to *double* / *real* / *boolean* / *integer* reservation: i'd like to see these aliases (and the is_*-functions etc) be deprecated / removed sooner than later instead of kept around. It's minor, i know, but consistency wins above a quick find/replace above all. With lesser roads to the destination (rome), the easier the route to follow ;) Atleast have it on a roadmap somewhere instead of keeping it around and in every discussion with regards to reserved keywords, typehints, return types etc etc Thanks and keep up the good work ! (can't wait to see what PHP7.0 will actually bring to the table) Thnx, Robin Speekenbrink 2015-02-20 17:11 GMT+01:00 Andrey Andreev : > Hi, > > > > […] > > Well, I meant to deprecate `is_double()`, is_real() and the > corresponding explicit casts. I might be missing other places when > they are used, not sure, but the point would be to stop using these > names for scalar types at all, so that everybody can freely use them > for class/trait/interface names ... I don't think anybody would do > that only for pseudo-scalar hinting objects. > > So, while yes - that's outside of this RFC's scope, reserving them as > keywords would be the opposite of what I had in mind. > > Cheers, > Andrey. --- ## #83332 — Sara Golemon — 2015-02-20T17:53:12+00:00 URL: https://externals.io/message/83254#83332 · In reply to: #83315 > > […] > > If someone wants to reserve these I will leave them up to another RFC, > as I suspect they are more controversial than what I have proposed. > Done https://wiki.php.net/rfc/reserve_even_more_types_in_php_7 -Sara --- ## #83334 — francois@php.net — 2015-02-20T18:05:51+00:00 URL: https://externals.io/message/83254#83334 · In reply to: #83288 Hi Andrey, I think the question of reserving 'resource' or not is not the main one. The question of having to reserve keywords is much more fundamental and needs to be addressed first. I expect it to be clear for everyone that, as long as we share the same naming space between class/interface/trait names and type hinting keywords, each addition of a new keyword will be a real problem. So, we may reserve keywords in advance but it cannot be more than a workaround. If we don't address the issue now, we'll end up with weird names for type hints, just because appropriate ones are *too appropriate* and potentially taken for existing or future classes, without any way to evaluate the potential BC break, let alone the potential introduction of a third naming space with a future 'typedef' feature ;). We see the case today with 'resource' but that's just the beginning. What about 'mixed', 'scalar', or others I don't imagine yet ? The race to reserving keywords is lost in advance. Another point is that, thinking the reverse way, developers can legitimately ask why they cannot choose 'resource' as a class name, when the reason for this is a design mistake made when the 'array' type hint was introduced, or even before, when class hints were introduced without thinking the mechanism would be necessarily be extended. Just a detail: I respectfully suggest anyone not to waste time to explain that the problem is solved by using lowercase-only keywords, at least not to me ;) So, we need to propose a migration path towards a cleaner syntax. The STH RFC we are writing proposes one, keeping it as smooth as possible because the feature is heavily used. Back to the particular case of 'resource': As the future of resources may be to be converted to objects while keeping the same API, the STH RFC will propose to define the 'resource' type hint as accepting 'IS_RESOURCE|IS_OBJECT', without conversion. Then the user who received it can distinguish with is_resource/is_object() if needed. So, 'resource' and 'resource|object' will be synonyms, while more precise users can use something like 'resource|object(GMP)'. All of these syntaxes will provide full BC when switching from resource to OO. Thought ? Regards François --- ## #83335 — Pierre Joye — 2015-02-20T18:22:26+00:00 URL: https://externals.io/message/83254#83335 · In reply to: #83318 > > Hi, > > > > […] wrote: > > […] > > Well, I meant to deprecate `is_double()`, is_real() and the > corresponding explicit casts. I might be missing other places when > they are used, not sure, but the point would be to stop using these > names for scalar types at all, so that everybody can freely use them > for class/trait/interface names ... I don't think anybody would do > that only for pseudo-scalar hinting objects. > > So, while yes - that's outside of this RFC's scope, reserving them as > keywords would be the opposite of what I had in mind. Right, but it is a yes/no list of options. It makes no sense to have competitive RFCs for such a trivial set of choices. > Cheers, > Andrey. --- ## #83352 — Andrey Andreev — 2015-02-20T20:16:24+00:00 URL: https://externals.io/message/83254#83352 · In reply to: #83334 Hi, > Hi Andrey, > > I think the question of reserving 'resource' or not is not the main one. > > The question of having to reserve keywords is much more fundamental and needs to be addressed first. I expect it to be clear for everyone that, as long as we share the same naming space between class/interface/trait names and type hinting keywords, each addition of a new keyword will be a real problem. So, we may reserve keywords in advance but it cannot be more than a workaround. If we don't address the issue now, we'll end up with weird names for type hints, just because appropriate ones are *too appropriate* and potentially taken for existing or future classes, without any way to evaluate the potential BC break, let alone the potential introduction of a third naming space with a future 'typedef' feature ;). We see the case today with 'resource' but that's just the beginning. What about 'mixed', 'scalar', or others I don't imagine yet ? The race to reserving keywords is lost in advance. > > Another point is that, thinking the reverse way, developers can legitimately ask why they cannot choose 'resource' as a class name, when the reason for this is a design mistake made when the 'array' type hint was introduced, or even before, when class hints were introduced without thinking the mechanism would be necessarily be extended. > > Just a detail: I respectfully suggest anyone not to waste time to explain that the problem is solved by using lowercase-only keywords, at least not to me ;) > > So, we need to propose a migration path towards a cleaner syntax. The STH RFC we are writing proposes one, keeping it as smooth as possible because the feature is heavily used. > > Back to the particular case of 'resource': As the future of resources may be to be converted to objects while keeping the same API, the STH RFC will propose to define the 'resource' type hint as accepting 'IS_RESOURCE|IS_OBJECT', without conversion. Then the user who received it can distinguish with is_resource/is_object() if needed. > > So, 'resource' and 'resource|object' will be synonyms, while more precise users can use something like 'resource|object(GMP)'. All of these syntaxes will provide full BC when switching from resource to OO. > > Thought ? > Sorry François, but I really didn't intend to go further into that topic. If Levi decides to add it as a second, optional vote - it's his proposal and that's fine with me. I only expressed my opinon about your suggestion to also reserve 'resource', because I don't have voting karma and RFC discussion is my only way of influencing decisions. Cheers, Andrey.