Hi Dennis, I didn't consider defining builtin type hints as classes because :
- I think it would be slower, and we need speed, but I agree, I did no test - no pre-defined namespace exists to handle this - Reverting to the root namespace makes it twice slower. The case of functions is nothing more than a hack to have a flawed design approved by all means. - Storing builtin types in the root namespace would cause exactly the same problem of sharing a naming space with user-defined names. - and probably the most important one: the implementation is based upon the ZPP layer, which allows internal and userland type hinting to follow exactly the same logic. About namespaces : no type hinting feature is currently planned at the namespace level, except the usual class resolution when a class name is used as hint. Some may exist in the future as there will probably be more links between built-in types and classes, such as specializing and combining builtin types using a userland class or exposing builtin-types as classes. Regards François > -----Message d'origine----- > De : Dennis Birkholz [mailto:den...@birkholz.biz] > Envoyé : vendredi 20 février 2015 22:22 > À : internals@lists.php.net > Objet : Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7 > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
