Hi Dennis, Please give more precise examples. I'm afraid I don't understand :
If you use \ as prefix for builtin types, how do you distinguish this from classes ? Would \resource mean the builtin type or a class name ? Do you mean no class could be defined under \ ? Syntax for union types ? Regards > -----Message d'origine----- > De : Dennis Birkholz [mailto:den...@birkholz.biz] > Envoyé : samedi 21 février 2015 07:06 > À : internals@lists.php.net > Objet : Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7 > > Hi François, > > Am 21.02.2015 um 03:03 schrieb François Laupretre: > > I didn't consider defining builtin type hints as classes because : > > I was not proposing using internal types as classes. I just want to > define a clean behavior for all kinds of types that may exist some time > in PHP. As no scalar type hints RFC has passed so far, we could also > define it in a clean way and just put the scalar types into \, then we > can not have the conflicting classes there and have to use "function > foo(\int $c)" instead of "function foo(int $c)" which is a lot better > that switching type hints for classes to something like "function bar > (object(my\namespaced\class) $a)". > > > - I think it would be slower, and we need speed, but I agree, I did no test > > I don't know this. > > > - no pre-defined namespace exists to handle this > > There is \ > > > - 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. > > Also you could just "use \int, \string;" on top of the file, than > "function foo(int $c)" is ok. In total, I think that is the BC-break > safe way to go, it will keep the door wide open for union types, etc. > without the worry of BC breaks. We could leave out all the hacky stuff > here. We could even use \PHP as the namespace to go. > > > - Storing builtin types in the root namespace would cause exactly the same > problem of sharing a naming space with user-defined names. > > No, because you can just move you classes into a namespace and add some > use statements to the top of the consumer files (with different > namespaces in use). With the current proposals, you have to invent new > names for you classes. > > > - 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. > > I consider this a detail that should not prevent a clean language > design. It may mean more work in the short time but I think this will > greatly increase the adoption rate if we can eliminate the BC break here. > > > 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. > > 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
