Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:16265 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35690 invoked by uid 1010); 17 May 2005 13:26:50 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 13664 invoked from network); 17 May 2005 13:07:57 -0000 Received: from unknown (HELO omniti.com) (127.0.0.1) by localhost with SMTP; 17 May 2005 13:07:57 -0000 X-Host-Fingerprint: 66.80.117.3 longsword.omniti.com Linux 2.5 (sometimes 2.4) (4) Received: from ([66.80.117.3:33485] helo=mail.omniti.com) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id DC/FD-01538-DACE9824 for ; Tue, 17 May 2005 09:07:57 -0400 DomainKey-Status: good X-DomainKeys: Ecelerity dk_sign implementing draft-delany-domainkeys-base-01 DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=test; d=omniti.com; h=Received:In-Reply-To:References:Mime-Version:Content-Type:Message-Id:Cc:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=HMO7AkGfsLG2aSFUNwlmDlckBR9EcFJAoXv1BQfeBbjPPHoxHAk0OHye6OXxM7/Z Ubl7uFvX25vnMkJQ0MN0ICTeGDrTnVHkm/GeHYQ6Bn7XRzFucj7ghW8DzDik/xi8 Received: from ([66.80.117.2:50486] helo=[10.80.116.151]) by mail.omniti.com (ecelerity HEAD r(4355M)) with SMTP id 92/B3-25344-9BCE9824 for ; Tue, 17 May 2005 09:08:15 -0400 In-Reply-To: <4289DDBA.8020809@3gupload.com> References: <4288F183.7010804@3gupload.com> <4289DDBA.8020809@3gupload.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: <675A247B-B932-4113-ADCF-AE3F82C8204D@omniti.com> Cc: George Schlossnagle , Derick Rethans , PHP Developers Mailing List Content-Transfer-Encoding: 7bit Date: Tue, 17 May 2005 09:07:46 -0400 To: Blake Matheny X-Mailer: Apple Mail (2.728) Subject: Re: [PHP-DEV] Patch for php_error_cb From: george@omniti.com (George Schlossnagle) On May 17, 2005, at 8:04 AM, Blake Matheny wrote: > Is there anything incorrect/wrong with the solution I proposed? I > realize that a custom extension would also work, but there are > several advantages to doing it the way I implemented it > > - No need to add an extension every time you upgrade PHP You can of course dynamically load extensions from your ini, and they only need to change when the API version changes. What you have is essentially a special purpose extension. The situation is that you want to provide an alternative type of extension to accomplish something that can already be accomplished through an extension (and which was designed to support exactly the things you're trying to do (and more)). That sort of redundancy isn't very useful. George