Well, how about renaming the functions, create aliases for BC and throw E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled with the distribution to migrate to the new convention?
On Fri, Jan 25, 2013 at 1:41 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote: > 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 > >
