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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
