Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71491
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4AzUWh4-DALP_-fkpfPB+CMK4NvNJ2ByzmAUz2wGW8n4w@mail.gmail.com>
References: <CADajX4AzUWh4-DALP_-fkpfPB+CMK4NvNJ2ByzmAUz2wGW8n4w@mail.gmail.com>
Date: Fri, 24 Jan 2014 10:44:38 +0100
Message-ID: <CAF+90c_ifnYCJSWLgKQFPr88BDQ+4fGP_2F7gPz1GTg111dpXA@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1bce8d6aad204f0b4346d
Subject: Re: [PHP-DEV] Ruminations on PHP 5++
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11c1bce8d6aad204f0b4346d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 24, 2014 at 7:34 AM, Adam Harvey <aharvey@php.net> wrote:

> Internaleers!
>
> We seem to have a few things being discussed at the moment that are
> somewhat beyond the scope of the sorts of changes we've been adding
> since 5.3. (I think the new release and voting processes have
> generally worked well here, incidentally: 5.4 and 5.5 have both been
> releases with a good range of new features, yet haven't caused
> significant pain in terms of BC and have been pretty stable.) Things
> that fall into that category for me include:
>
> 1. size_t and int changes.
> 2. Generics.
> 3. Function and method naming rationalisation (whether through
> aliasing existing functions, or adding a new API through enabling
> method calls on scalar variables).
> 4. Dare I say it, better multibyte encoding handling. (I don't want to
> repeat the PHP 6 experience, but I'm also not sold on mbstring-ng
> being the ultimate solution.)
> 5. Named arguments.
> 6. Unbundling of ext/mysql and removal of features deprecated in 5.4 and
> 5.5.
>

I agree that the time has come. We have accumulated a number of big changes
which would benefit from a major-version jump and some of us are also eager
to introduce some BC breaks ;)

My schedule recommendation would be to give PHP6 at least two years after
5.6. After all, it's a larger change, so we'll presumably need more time.

Is there any problem with using the current master branch as PHP6 right
away? 5.7 (should it exist) can be branched off 5.6 after all.

Nikita

--001a11c1bce8d6aad204f0b4346d--