Hi, On Fri, Feb 20, 2015 at 8:05 PM, François Laupretre <franc...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
