Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.185 cause and error)
Message-ID: <5107E02D.6050204@lsces.co.uk>
Date: Tue, 29 Jan 2013 14:43:57 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <5d21b42656d49b4a71d9f808541bd745@mail.gmail.com> <CAJW__o37e4gK9oA2pLEqK5siLNRvm=ojTD7=pC_rUHMm7=59oA@mail.gmail.com> <2867ee446726884cd1ac3c2d185499b4@mail.gmail.com> <CAJW__o2ZRoZSe4_RiUB1X_uxmyeFihiSh=vj7vB-zp8cKe-egQ@mail.gmail.com>
In-Reply-To: <CAJW__o2ZRoZSe4_RiUB1X_uxmyeFihiSh=vj7vB-zp8cKe-egQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
From: lester@lsces.co.uk (Lester Caine)

Kalle Sommer Nielsen wrote:
> 2013/1/29 Zeev Suraski<zeev@zend.com>:
>> >The RFC explains the pros and cons of doing that, I don't really have any
>> >additional reasons to add beyond what I already put there.  I believe the
>> >pros outweigh the cons by a good considerable margin, but that's what the
>> >vote would be about.  Perhaps the one thing worth adding is that the
>> >people who worked on Optimizer+ are all major php.net contributors,
>> >including Dmitry, Stas, Andi and myself - it's not some alien artifact.
> I don't doubt any of your abilities, what I do doubt is that how we
> can consider an outside project directly into the core. APC would
> without a doubt be up to pair if there was more people willingly to
> dwell into it (yes dwell as many people see it as an alien artifact
> because it touches and modifies some "unusual" things that the average
> extension developer don't).

A fresh injection of 'blood' may do wonders? Since there are other options to 
APC which may be alternative candidates, on one hand it makes perfect sense that 
such a knowledgeable clean sheet is at least considered especially since the 
code is almost feature complete? But providing it as another external (PECL) 
option initially makes more sense? If only to allow comparison with APC, 
eaccelerator and the rest?

I'll get my head chewed off again, but can we no consider doing that as PHP6 
given that 6.0.x could be a development stage. I would perhaps then strongly 
lobby for 'only' having E_STRICT mode so things like 'static $this' go by the by 
anyway? This would not rule out a 5.5 with just the current suit of extras 
although personally I'd prefer a longer maintained 5.4  with just the extras 
that dovetail well included.

-- 
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