On Fri, Jan 24, 2014 at 5:50 PM, Larry Garfield <[email protected]> wrote:
> On 1/24/14 10:31 AM, Julien Pauli wrote:
>>
>> On Fri, Jan 24, 2014 at 5:18 PM, Andrea Faulds <[email protected]> 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's a mandatory request yes. We make this language for our users,
so we absolutely have to listen to them.
As usual, we won't be able to satisfy everyone, but we definetly have
to listen to our user base.
>
> 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.
Yep, PHP5 was a major rewrite from an internals POV, but still keeping
the same PHP4 VM base principles.
Rasmus or any guy who participated in such a rewrite could give a word about it.
Its
> also a place that leaning on HHVM (either for code, or concepts, or
> something) would be very valuable.
Yup, however, we still have a goal => beeing able to run on any
machine, any platform (well, a large part of)
I like HHVM, but it is a Facebook product, fitting FaceBook's own needs.
PHP is not to be tied to a particular architecture, PHP still has to
run everywhere, everytime, and still has to be very extensible.
That's what made its glory, and I think we must keep those objectives.
That is also what makes developping PHP itself a true challenge, so interesting.
Julien