Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61090 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2235 invoked from network); 3 Jul 2012 15:39:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jul 2012 15:39:06 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:58994] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 31/11-30242-81213FF4 for ; Tue, 03 Jul 2012 11:39:05 -0400 Received: (qmail 31386 invoked by uid 89); 3 Jul 2012 15:39:01 -0000 Received: by simscan 1.3.1 ppid: 31378, pid: 31383, t: 0.3034s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO ?66.206.217.239?) (lester@lsces.co.uk@66.206.217.239) by mail4.serversure.net with ESMTPA; 3 Jul 2012 15:39:01 -0000 Reply-To: Lester Caine To: PHP Internals X-Mailer: Modest 3.2 References: <4FF2FFBF.8050301@lerdorf.com> In-Reply-To: Content-Type: multipart/alternative; boundary="=-Ix0HVmJwfWHLLihxhfpm" Date: Tue, 03 Jul 2012 11:38:57 -0400 Message-ID: <1341329937.1595.18.camel@Nokia-N900> Mime-Version: 1.0 Subject: Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet? From: lester@lsces.co.uk (Lester Caine) --=-Ix0HVmJwfWHLLihxhfpm Content-Type: text/plain; charset=utf-8 Content-ID: <1341329936.1595.15.camel@Nokia-N900> Content-Transfer-Encoding: 7bit > > It is still the case. > > > > I for one would like to kill all the legacy features or too specific > > features which are really unusable by any common developers. > > > > Other developers may disagree but it makes very hard to maintain APC. > > Perhaps that indicates it's time to pull the core of APC into php's > core... Just the core, not all of those other features. Then the APC > extension can still exist for those additional legacy features, but > the core functionality can be shipped with PHP itself. > > I know there was talk about adding that to php6 by default, perhaps > 5.5 (or 5.6) could benefit from it... > > Thoughts? Would that provide an sufficent improvement over the alternatives to justify forcing it's general use. I still prefer eaccellerator from a performance point of view ... And others do prefer the alternatives. Almost worth asking which Is prefered. --=-Ix0HVmJwfWHLLihxhfpm--