Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65181
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender)
Message-ID: <5102D1DB.9060305@sugarcrm.com>
Date: Fri, 25 Jan 2013 10:41:31 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: =?ISO-8859-2?Q?Damian_Tylczy=F1ski?= <turneliusz@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGsPR66hpGfvtZQw9A_-Jc-jqEdhWkbq8km1GYZ0K9Ycx9Vn1w@mail.gmail.com>
In-Reply-To: <CAGsPR66hpGfvtZQw9A_-Jc-jqEdhWkbq8km1GYZ0K9Ycx9Vn1w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers
 more attention
From: smalyshev@sugarcrm.com (Stas Malyshev)

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