Hi! > Yeah, it’s a problem. I think some breakage here is inevitable, > unfortunately. Some of the classes with these names are stand-ins for > scalar type hints, so that code can “just” migrate to using actual > hints. But this doesn’t apply to all of them.
Breaking ZF2 and all software built on it is not "some breakage", it's a serious issue which would produce a big barrier for PHP 7 migration. And looks like there are more frameworks that do the same. This would be a barrier to PHP 7 adoption, and note that is even for people that couldn't care less for scalar typing. We'd find ourselves in python 3 situation - where people would be glad to upgrade but they use library X and it doesn't work and they have no idea how to fix it and they keep all their development on the old version and the new one never catches on. It'd be a shame if we spend all this effort on PHP 7 and get no adoption since people can't run their existing code on it. > We could choose to simply not prohibit them as class names, but that > creates a weird inconsistency where you can make ‘class Integer’ yet > ‘function foo(Integer $a)’ hints against the integer type, not your > class. Type hints are very widely used, so I doubt this would help > anyone, and we’d still be breaking existing code type hinting against > such classes. I'd rather make the hints case sensitive. In fact, of two BC breakages making classes case sensitive may be the lesser one (I'm not a big fan of either but at least the modern frameworks would probably all work and if some code does not it's possible to auto-fix it). > There’s not much we can do really. I suppose there is one positive > outcome, in that hopefully when broken code is updated to work, it > might have more descriptive class names. :) The issue here is that people that now use ZF2 or other framework like that won't rewrite it. They would just stay on PHP 5. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
