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
