Hello
Am 20.02.2015 um 22:03 schrieb François Laupretre:
>> I just wonder why we need to prohibit these names. Can types not reside
>> in the global \ namespace? We could then change the class resolution
>> rules to allow to look also in \ as is done for functions currently.
>>
>> Thanks
>> Dennis
>
> This is not a question of namespace resolution. Built-in type hints and
> namespaces have nothing in common.
I do not know how the actual implementation works, but I assume there is
a symbol table for each namespace that contains a list of
class/trait/interface names for that namespace. Why not enhance this
mechanism to contain all type information for each namespace? Simple
types go into that symbol table, type aliases, type defs/enum types (if
such a thing gets implemented), union types, etc. In addition, if the
current namespace symbol table does not contain an entry (and the
autoloader fails), the root namespace is tested for a name.
> It is just about the logic of :
>
> Class resource {
> ...
> }
>
> Function foo(resource $arg, ...)
>
> Do we check $arg to be I_RESOURCE or an instance of the 'resource' class ?
The class definition would give an error, as "resource" already exists
in the topmost namespace.
namespace test {
Class resource { ... }
function foo(resource $arg, ...)
}
function bar(resource $arg, ...)
foo uses the class test\resource, bar uses the resource type from the
root namespace.
Maybe PHP works completely different internally and this is not
feasible. But reserving some names from being valid as a class name
sounds like a hack, I would prefer a clean and generic solution.
Thanks
Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
