Hi! > I've seen discussion on reddit > http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ > where many people are surprised why PHP can't have this done. Why > inconsistency is something that we want to keep because of backward > compatibility. PHP already introduced many backward compatibility
I don't think you can just hand-wave the issue away by saying "PHP introduced BC breaks". First, PHP practically never introduced BC breaks that breaks almost all existing code. Even when we did huge changes - like OO model change - we had compatibility mode for a long time, and that considering in most scenarios it still worked the same. BC breaks happened, but they mattered only in some specific scenarios and usually this was done because old way of doing it could no longer be practically used or lead to bigger problems than BC (such as security issues or frequent hard-to-find bugs). Second, here we have breakage that would happen just for the sake of satisfying some people that thing having or not having underscore in function name really matters. For 99% of people out there, it does not. I agree it'd be nice if we came back in time and wrote function naming standard before PHP functions were implemented. But since we can't go back in time, we have to choose between things that matter to most of people - e.g., compatibility and code that keeps working when upgrading to next PHP version - against naming beauty that doesn't matter for most of them. I agree that beautiful is better than ugly. But, ugly but working is better than beautiful but broken. > names were created by some crazy "let's imagine some name and don't > look at API we have" man? Why we can't have PHP 6 that will be not > some amazingly featured-packed version but version with API that > just... makes sense. Because there would be zero incentive to upgrade to it for any current user. You'd have to rewrite and retest your code with zero benefit. And you'd have to maintain two codebases from now on for any application that is supposed to run on both, or resort to all kinds of trickery to keep it working. As someone working with 600K+ LOC code base, I don't see doing that as something I'm eagerly waiting for. Then the question is - why would we release a version that 99% of existing users would hate to use? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
