On Thu, 14 Feb 2008, Markus Fischer wrote:
> 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.
I remember why it was added. It was because of PEAR having to set an
include path. Stig added this function because many shared hosters (or
atleast enough) were disabling ini_set(), and thus you couldn't set a
required include path.
As to this issue, I don't think we should add two new functions here
either.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
