Hi, > De : Stanislav Malyshev [mailto:smalys...@gmail.com] > > There was a lot of discussion about this topic. Right now, unless > there's a proposal to fix it that works, I don't see what can be done > about it.
I wrote a long message some months ago to explain why reserving names was, IMHO, the wrong way to go (https://www.mail-archive.com/internals@lists.php.net/msg75672.html). The problem comes from authorizing bare class names as type hints. That’s history, none to blame here, it should just have been solved when type hints were extended to arrays, but, with the extension to scalars, it is now urgent. Solving conflicts one by one, and discussing whether 'String' is a bad choice for a class name, or if it should be reserved in a case-sensitive way, won't solve anything. 'String' is just the first one to jump in. Consider 'Resource', 'Object'... All potential endless discussions to clutter the mailing list and make users afraid of switching to 7. Potential result : the old circle Johannes is talking about and the python 2/3 effect. I think we need to consider we have a name conflict, as we are using the same name space for two different concepts, and decide a long-term strategy to address it, preferably before releasing 7.0. Once again, I propose what I still consider as the only long-term solution proposed so far : slowly, step by step, deprecate the usage of bare class names as type hints. It looks like a huge break, and it is, but we can make it smooth. Here are the steps I have in mind : - In 7.0, introduce the 'object' (accepts any object instance) and 'object(ClassName)' (similar to the bare 'ClassName') type hint syntaxes. Bare class names are still recognized and priority is given to class names (if a 'String' class is defined, every 'String' or even 'string' type hints will always refer to it). So, compatibility is preserved, even if class names conflict with scalar type hints. Prominent frameworks will easily change their 'String' type hints to 'object(String)' and be prepared for the next step. Anyway, they have several years to do it and the most important is that they keep their class names. - In a second step, probably in 8.0, and with a prior deprecation message introduced in a 7.x version to define, remove support for bare class names as type hints. This step can be refined later. The most important is to introduce the target syntax as soon as possible. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
