Re: Re: [RFC] Reserving More Types in PHP 7

Hi, On Fri, Feb 20, 2015 at 8:05 PM, François Laupretre <francois@php.net> wrote: > 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.