Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79103
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54705FFB.8040200@lsces.co.uk>
Date: Sat, 22 Nov 2014 10:05:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <3d131946349b68aa2ae26dcfeaa5197a@mail.gmail.com>	<CAH-PCH6HTTcA+Y-UWi_8kZjtMSKRp3sRmRzS3VWdMYwSXgKeJA@mail.gmail.com>	<2FCFF6B7-53FB-4D56-9296-371374F79C78@zend.com>	<CAH-PCH65RsdW6wgTiC77Hb-1_wFXn4TyqJy_3zVJnediY+dUqw@mail.gmail.com>	<c3ec0064df9735f78d372f431deb4ccc@mail.gmail.com> <CAEZPtU5RBPT6PypTUNPw2tnyp3-kg8zCXZHdDyhRFntbQMVS4A@mail.gmail.com>
In-Reply-To: <CAEZPtU5RBPT6PypTUNPw2tnyp3-kg8zCXZHdDyhRFntbQMVS4A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline
From: lester@lsces.co.uk (Lester Caine)

On 22/11/14 09:14, Pierre Joye wrote:
> That's why I strongly suggest to make a more realistic time plan and
> stick to it. Specific dates can or should be define later but the
> period (mid october f.e.) should be defined now. One week more when it
> is about fixing one last critical bug for an existing feature is
> perfectly OK, 1 month to actually finish a new feature may not be
> good, at all.

When a customer tells me I have to give him a completion date I have a
stock answer. 'When you sign off on the specification'. The current
problem is that we have no idea just what form PHP7 is going to take,
and no idea just how much code will need to be reworked as a result.

There is a lot of parallel developments going on all with different
goals and in my book all at odds with a cohesive roadmap? Many people
want their pet features included ASAP but as yet there is no agreement
even on what PHP7 will be? Until there are a set of goals any planning
on time is irrelevant.

It IS all chicken and egg since one can't know now just how long it will
take to do some of the things being discussed, and it may be that it's
impossible to achieve a preferred goal in a reasonable time frame? THAT
is basically what happened with PHP6? The selections made for the goal
turned out to be the wrong ones but it took time for people to give in
ad scrap that roadmap.

From a user point of view I'd rather know what will NOT be part of PHP7
early, and anything being removed will be tagged as deprecated in PHP5.7
... I don't see any way forward without a bridging build to help
identify code that needs work, and I would like to make a case for NOT
loading PHP7 down with compatibility switches like e_strict! Lets keep
the compatibility aspect to PHP5.7 and those of us who don't have time
to 'upgrade' will continue to run PHP5 for another 10+ years. PHP7
should be - hopefully - a single clean interface with in my book UTF8
capability as a bare minimum. But I don't think we need Python3 type
breaks to achieve this since much of the core has already had UTF8
sneaked in via the back door. I'm thinking more like a C -> C++ break
where the core procedural framework still works, but people can add OO
namespaces on top which do not have to be 'required'. I just don't see
how the 'everything must be exceptions' camp can be accommodated with
procedural error handling?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk