RE: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7
| From: | François Laupretre | Date: | Fri, 20 Feb 2015 18:05:51 +0000 |
| Subject: | RE: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7 | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83334@lists.php.net to get a copy of this message | ||
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