Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35484 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45258 invoked by uid 1010); 14 Feb 2008 09:20:20 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 45243 invoked from network); 14 Feb 2008 09:20:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Feb 2008 09:20:20 -0000 Authentication-Results: pb1.pair.com header.from=markus@fischer.name; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=markus@fischer.name; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fischer.name from 213.46.255.22 cause and error) X-PHP-List-Original-Sender: markus@fischer.name X-Host-Fingerprint: 213.46.255.22 viefep18-int.chello.at Solaris 10 (beta) Received: from [213.46.255.22] ([213.46.255.22:58216] helo=viefep19-int.chello.at) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4D/00-43552-2D704B74 for ; Thu, 14 Feb 2008 04:20:19 -0500 Received: from genuine.home ([84.112.136.139]) by viefep19-int.chello.at (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20080214092015.ZGCZ13912.viefep19-int.chello.at@genuine.home>; Thu, 14 Feb 2008 10:20:15 +0100 Received: from ncvielp07.home ([192.168.1.51]) by genuine.home with esmtpa (Exim 4.50) id 1JPaFy-0002Rs-BE; Thu, 14 Feb 2008 10:19:50 +0100 Message-ID: <47B407CD.2060709@fischer.name> Date: Thu, 14 Feb 2008 10:20:13 +0100 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lars Strojny CC: Jochem Maas , Pierre Joye , PHP Internals List References: <1202917630.25345.6.camel@localhost> <1202943887.7717.7.camel@localhost> <47B383C1.3030303@iamjochem.com> <1202980076.7717.12.camel@localhost> In-Reply-To: <1202980076.7717.12.camel@localhost> X-Enigmail-Version: 0.95.6 OpenPGP: id=C2272BD0; url=http://markus.fischer.name/my_public_key.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -43 X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "genuine.home", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Lars Strojny wrote: > Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas: >> I think Lars has a point ... maybe set_include_path() could >> be given a second parameter instead to mitigate the need for seperate >> funcs?: >> >> set_include_path('foo', INCPATH_OVERRIDE); // default >> set_include_path('foo', INCPATH_APPEND); >> set_include_path('foo', INCPATH_PREPEND); > > Thanks for your support, but this seems counter intuitive. Why should > *set*_include_path() be used to *append* or *prepend* to the include > path? Also learning another mouthful of constants is maybe suboptimal. > Getting used to prepend_/append_...() is easy from my point of view, as > the name is derived from what's currently present (set_include_path()). [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -3.3 ALL_TRUSTED Did not pass through any untrusted hosts -1.1 BAYES_40 BODY: Bayesian spam probability is 20 to 40% [score: 0.2252] Subject: Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path() From: markus@fischer.name (Markus Fischer) Lars Strojny wrote: > Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas: >> I think Lars has a point ... maybe set_include_path() could >> be given a second parameter instead to mitigate the need for seperate >> funcs?: >> >> set_include_path('foo', INCPATH_OVERRIDE); // default >> set_include_path('foo', INCPATH_APPEND); >> set_include_path('foo', INCPATH_PREPEND); > > Thanks for your support, but this seems counter intuitive. Why should > *set*_include_path() be used to *append* or *prepend* to the include > path? Also learning another mouthful of constants is maybe suboptimal. > Getting used to prepend_/append_...() is easy from my point of view, as > the name is derived from what's currently present (set_include_path()). Just my "senf" (like 2c, but that's what we call it in Austria :) Personally I never understood why we've set_include_path in the first place anyway. "ini_set('include_path', ..." does exactly the same and the C function does actually exactly this. If this function would have been here since PHP4, fine. But personally, I don't see a justification to introduce a new function for such a simple thing. Considering we've already two ways to achieve the same goal I don't see a reason to add another two ways to deal with simple string handling. There's not verification/validation whatsoever done. - Markus