Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71519
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
Message-ID: <52E299D4.6040102@garfieldtech.com>
Date: Fri, 24 Jan 2014 10:50:28 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CADajX4AzUWh4-DALP_-fkpfPB+CMK4NvNJ2ByzmAUz2wGW8n4w@mail.gmail.com> <52E29253.2000801@lsces.co.uk> <52E2924B.6080002@ajf.me> <CAMUwpuS0KzwJWO=8Pfxdfwe8BuYPcPLHTrcB7ubfafXJ2020FQ@mail.gmail.com>
In-Reply-To: <CAMUwpuS0KzwJWO=8Pfxdfwe8BuYPcPLHTrcB7ubfafXJ2020FQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Ruminations on PHP 5++
From: larry@garfieldtech.com (Larry Garfield)

On 1/24/14 10:31 AM, Julien Pauli wrote:
> On Fri, Jan 24, 2014 at 5:18 PM, Andrea Faulds <ajf@ajf.me> wrote:
>>
>>
>> On 24/01/14 16:18, Lester Caine wrote:
>>>
>>> Adam Harvey wrote:
>>>>
>>>> Adam, who loves starting a good flame war on a Friday.
>>>
>>> It would perhaps be nice to avoid the same mistakes that Python made
>>> when re-factoring 3.0 and not taking the rest of the user base with
>>> them. The level of breaking of BC needs to be carefully balanced?
>>> And I still think that 5.4 should have been a major hike which would
>>> have allowed a little more flexibility then.
>>
>>
>> There is a lot that PHP's 5/6 transition can learn from Python's 2/3
>> transition. One might be, IMO, not to backport any new features. Otherwise
>> people will simply keep using 2/5 instead of 3/6, due to the features also
>> being available there.
>
> Big +1 , Python 2 to 3 should be taken care of when thinking about PHP5++.
>
> Also, we should remember what we actually did from PHP4 to PHP5.
> We changed the objects management (that was the biggest change), and
> even with a compatibility mode INI settings which was pretty hard to
> develop from an internal POV, it still took AGES for people to migrate
> from 4 to 5, mainly because of "compatibility issues" regarding
> objects, and because of the new error reporting system showing much
> more messages on badly designed code in PHP5 than it did in PHP4.
>
> I wasnt an internal guy at this time, but I still remember 2004 pain.
> Everybody felt enthusiast , PHP 5.0 was a pretty nice product , but it
> took about 5 to 7 years to finally jump to 5.X branch :-p
> Times have changed, PHP and all its ecosystem is nowadays more mature
> than before, but still...
>
> We must not do any mistake for PHP6 , nobody will pardon a mistake.
> Every wrong step or decision could lead to PHP's death , we really
> have to take care of everything.
>
> Julien

Coordinating with user-space projects will be critical to avoiding that 
same chicken-and-egg problem.  It took 100+ projects banding together to 
declare "we're mad as hell, and don't give a crap about PHP 4 anymore" 
to finally make that transition happen, and that was 3 years after PHP 
5.0 was released.  If we want PHP 5++ to have an easier transition 
period (yes please!), we need to coordinate that with major projects and 
frameworks to make sure that they 1) Can up their requirements in a 
reasonable timeframe; 2) Have a good reason to do so; 3) Can all do so 
around the same time so that there's no "first mover penalty".

That sounds like a good topic for FIG to help with, and I'm happy to act 
as a coordinator between Internals and FIG around that.

I also agree with others who've said that PHP 5++ is the right time to 
heavily refactor/rewrite the engine itself, just as was done for PHP 5. 
  Its also a place that leaning on HHVM (either for code, or concepts, 
or something) would be very valuable.

--Larry Garfield