On Sun, Apr 26, 2015 at 1:36 PM, Nate Abele <nate.ab...@gmail.com> wrote: > On Sunday, April 26, 2015, Levi Morrison <le...@php.net> wrote: > > On Sat, Apr 25, 2015 at 8:27 PM, Nate Abele <nate.ab...@gmail.com> wrote: >>> Dear Internals, >>> >>> I would like to discuss a small RFC for reserving more types in PHP 7: >>> https://wiki.php.net/rfc/reserve_more_types_in_php_7 >> >> >> Welp, thanks for breaking my framework, everyone. >> >> It just *had* to be case-insensitive too, hm? > > I'm not sure what you want us to say. > > > Well, it looks to me like all the discussion is around preventing class and > namespace names like “string”, “float”, etc. Granted, PHP class names are > case-insensitive, but how hard would it be to reserve these in a > case-sensitive way?
Not necessarily hard, but it would create an inconsistency with other types. PHP has plenty of consistency problems already; do you *really* want to add a new one? > Lithium, CakePHP, and Drupal all have String classes. These aren’t small > projects. Not to mention the presumably untold numbers of developers who > have hand-rolled ‘type’ classes into their projects while waiting around for > scalar type-hinting support to land. And everyone’s cool with breaking all > of these? This was known at voting time, yes. Having an actual string type in PHP was a separate RFC that was accepted -- realize that while my RFC would have reserved it whether that other one passed or not the other RFC *did* pass, so effectively the RFC you linked only reserved true, false and null. > I get that PHP 7 is the big opportunity to break backward compatibility, but > yeesh, really? It’s like we’re not even trying anymore. The number of code bases using a string class is quite small when you compare it to the total number of PHP developers and code bases out there. I think you are blowing this out of proportion because you are directly affected by it. I get it -- my website at work was really hit hard in PHP 5, 5.3 and 5.4. We had some really crappy code that relied on register globals, some deprecated session functions, magic quotes, ext/mysql and other problems. After fixing each issue our codebase has been better off. If you can't afford to update an application then you need to seriously think about that since that application apparently isn't valuable enough for you to maintain it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
