Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.174 as permitted sender)
Message-ID: <52C61D21.50808@gmail.com>
Date: Fri, 03 Jan 2014 02:14:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAGa2bXZJoyV+9qN6v8j3+vHexoqDtHR4cZkgdtdc1GpVkDaD9w@mail.gmail.com> <CADNQb0WnEM8hE3=ns3fFaaqNdcBTAJUytvLY-G1C5pvB4tTgmA@mail.gmail.com> <52BE8F35.9090104@b1-systems.de> <52C4A415.3040101@gmail.com> <52C4ADC8.1090009@lerdorf.com> <52C510CF.3030604@garfieldtech.com> <0bae3e8fb5acff88a1aba0bea6bd264d@yamiko.org> <CAGa2bXaBjBH8arwmfv5xTmhNCoS8nLBhCKFPskSwQ0iBOhB1Fw@mail.gmail.com> <CAA9esyTXzAG3v=H=nFJ_k8V5FMm3n4Nh2gXB_4NnAX1XGHRPwg@mail.gmail.com>
In-Reply-To: <CAA9esyTXzAG3v=H=nFJ_k8V5FMm3n4Nh2gXB_4NnAX1XGHRPwg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP6] Function name consistency
From: rowan.collins@gmail.com (Rowan Collins)

On 02/01/2014 20:00, Florin Patan wrote:
> I suppose it wouldn't be a problem with having a tool that can
> generate an AST out of a .php file  and dump it back to a newer syntax
> (as long as only the function / method / classes name and parameter
> order is changing).

Don't forget that there are various ways to do what could loosely be 
described as "reflection" or "meta-programming" in PHP - e.g. given 
call_user_func_array($func, $args) we may need to correct the name 
stored in the string $func, or the order of items in the array $args.

These are very hard to even detect with an automated tool, let alone fix 
- indeed, I doubt it is even theoretically possible in many cases. That 
leaves you with either code that needs painstaking manual upgrades, or a 
runtime compatibility mode.

Both of these come with a cost to the community at large - many people 
want to distribute (or internally manage) code that is both backwards 
and forwards compatible, i.e. runs on as many past and future versions 
of the platform as possible. That's impossible to do with a hard 
compatibility break, and tricky if the compatibility breaks are subtle 
(such as new function names/aliases) as you have to keep testing and 
removing the new names until you no longer need to support the old versions.

A more fundamental restructuring (e.g. an OO implementation of "basic" 
operations) could more happily sit alongside the existing functionality, 
with code very obviously using either one style or the other, and 
compatibility easy to maintain over the longer term.

Regards,

-- 
Rowan Collins
[IMSoP]