Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5102D1DB.9060305@sugarcrm.com>
References: <CAGsPR66hpGfvtZQw9A_-Jc-jqEdhWkbq8km1GYZ0K9Ycx9Vn1w@mail.gmail.com>
	<5102D1DB.9060305@sugarcrm.com>
Date: Fri, 25 Jan 2013 13:55:23 -0500
Message-ID: <CAOtCo3qM5oQu4wpn_zhVpyPFDVemxKfBOmB2Qp7dKhUyoot2bw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: =?ISO-8859-2?Q?Damian_Tylczy=F1ski?= <turneliusz@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b66f6c34300d004d42178b0
Subject: Re: [PHP-DEV] I think that "Function naming inconsistency" bug
 deservers more attention
From: seva.lapsha@gmail.com (Seva Lapsha)

--047d7b66f6c34300d004d42178b0
Content-Type: text/plain; charset=ISO-8859-1

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 <smalyshev@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
>
>

--047d7b66f6c34300d004d42178b0--