Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72887
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.169 as permitted sender)
Message-ID: <5311EC85.50701@gmail.com>
Date: Sat, 01 Mar 2014 14:19:49 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c8VvR0QW12zdKpWxodGSaZRp+7Mp7vNGRjFM+V+eFZR0w@mail.gmail.com>	<5310F8BF.8090503@oracle.com>	<CAHXmDMBAEK=YkEySiaV9J6qfzru91urXbH=8rVz2JgoPa=bqZA@mail.gmail.com> <CAF+90c-8Ayb79iS9wMdRD_5sygV1Y50Et+MJ4nOaZv3aZbLTcg@mail.gmail.com>
In-Reply-To: <CAF+90c-8Ayb79iS9wMdRD_5sygV1Y50Et+MJ4nOaZv3aZbLTcg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Add support for PCRE marks
From: rowan.collins@gmail.com (Rowan Collins)

On 01/03/2014 00:30, Nikita Popov wrote:
> It's a bit ridiculous that you can end up using a PHP
> version from 2014 together with a decade old PCRE version.

That's an interesting way of looking at it. I don't know enough about 
the specifics of this case, but the general idea feels close to a 
conversation I had with a colleague the other day, in which he argued 
that it doesn't make sense to restrict a new project to an already 
out-of-date library just because that's what we're using elsewhere. 
Since we were discussing CSS frameworks, any upgrade of old projects 
would mean the site was getting a complete overhaul anyway - in the same 
way that a PHP 5.6 package would be expected to come with either a 
complete release of the distro, or some way of resolving "too new" 
dependencies.

I also think that many PHP *users* don't realise just how tightly PHP's 
extensions expose the specifics of a particular version of a 3rd-party 
library. They might look at the documentation to check that a particular 
function or option was added in PHP 5.4 or 5.5, but they probably 
wouldn't even consider checking what version of PCRE (or libxml, etc, 
etc) their system had, until they found something in their code 
mysteriously "broke" on a particular environment. From that point of 
view, the user-friendly approach for a PHP extension is to either 
*require* a newer version of a library, or expose only the "lowest 
common denominator" of functionality, so that the documentation can 
confidently say "in PHP 5.6, you can do this".

Like I say, I don't know about the specifics of this case, so raising 
the requirement may or may not be the right decision here, but it seems 
like a useful line of thought.

Regards,

-- 
Rowan Collins
[IMSoP]