Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
The current patch is in a bit hacky state, as I have my doubts whether
storing the include paths as a string is a good idea. I want to gain
some feedback for this addition first before I invest more work on it.
[1] http://lars.schokokeks.org/php/include_path_modifiers-1.diff
cu, Lars
Hi Lars,
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
I don't think we need two new functions for:
set_include_path('/some/path' . DIRECTORY_SEPARATOR . get_include_path());
set_include_path(. get_include_path() . DIRECTORY_SEPARATOR . '/some/path' );
Thanks for your work anyway! :)
Cheers,
Pierre Joye wrote:
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.I don't think we need two new functions for:
set_include_path('/some/path' .
DIRECTORY_SEPARATOR.get_include_path());
set_include_path(.get_include_path().DIRECTORY_SEPARATOR. '/some/path' );
Gotcha, it needs to be PATH_SEPARATOR, no?
- Markus
Pierre Joye wrote:
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.I don't think we need two new functions for:
set_include_path('/some/path' .
DIRECTORY_SEPARATOR.get_include_path());
set_include_path(.get_include_path().DIRECTORY_SEPARATOR. '/some/path' );Gotcha, it needs to be PATH_SEPARATOR, no?
That would be a reason to have these functions (yes, path_separator is
required) ;-)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hi Pierre,
Am Mittwoch, den 13.02.2008, 23:12 +0100 schrieb Pierre Joye:
[...]
That would be a reason to have these functions (yes, path_separator is
required) ;-)
So you agree? Thanks :)
cu, Lars
Hi Pierre,
Am Mittwoch, den 13.02.2008, 23:12 +0100 schrieb Pierre Joye:
[...]That would be a reason to have these functions (yes, path_separator is
required) ;-)So you agree? Thanks :)
I don't, it was a joke :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Hi Pierre,
Am Mittwoch, den 13.02.2008, 23:01 +0100 schrieb Pierre Joye:
[...]
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
[...]
I don't think we need two new functions for:
Sure?
set_include_path('/some/path' .
DIRECTORY_SEPARATOR.get_include_path());
See: prepend_include_path('/some/path');
set_include_path(.
get_include_path().DIRECTORY_SEPARATOR. '/some/path' );
See: append_include_path('/some/path');
Think about reading the code. What's easier to grasp for you?
Introducing this functions is meant to make a) code better readable, b)
easier to write the code, as most of the time, include path adjustments
are include path appends, so the roundtrip
set_include_path(get_include_path() ...) is not suboptimal.
On the other hand, introducing this functions will not very likely
introduce a lot of new bugs, so the maintenance overhead is lower than
the value this functions bring (of course this is my POV, as I wrote
that patch :-)). And, for the record, I promise to provide fixes for
each the related bug (everyone heard that?).
cu, Lars
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);
Strojny schreef:
Hi Pierre,
Am Mittwoch, den 13.02.2008, 23:01 +0100 schrieb Pierre Joye:
[...]the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
[...]
I don't think we need two new functions for:Sure?
set_include_path('/some/path' .
DIRECTORY_SEPARATOR.get_include_path());See: prepend_include_path('/some/path');
set_include_path(.
get_include_path().DIRECTORY_SEPARATOR. '/some/path' );See: append_include_path('/some/path');
Think about reading the code. What's easier to grasp for you?
Introducing this functions is meant to make a) code better readable, b)
easier to write the code, as most of the time, include path adjustments
are include path appends, so the roundtrip
set_include_path(get_include_path() ...) is not suboptimal.
On the other hand, introducing this functions will not very likely
introduce a lot of new bugs, so the maintenance overhead is lower than
the value this functions bring (of course this is my POV, as I wrote
that patch :-)). And, for the record, I promise to provide fixes for
each the related bug (everyone heard that?).cu, Lars
Hi Jochem,
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
setinclude_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()).
cu, Lars
Hi Jochem,
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
setinclude_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()).
Yeah, I agree that if at all I would go with Lars's original proposal.
I am +1 if we also commit array_merge_replace() at the same time :)
No seriously, its rare enough stuff that I do not see a special need
for these functions. But I do buy the argument that it improves
readability and is easier to remember (and get proper autocompletion
in an IDE). So I am +0.
regards,
Lukas
Lukas Kahwe Smith schreef:
Hi Jochem,
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
setinclude_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()).Yeah, I agree that if at all I would go with Lars's original proposal.
point taken, I was just thinking out loud really, I didn't even know of
set_include_path() before yesterday. I happily use ini_set('include_path') and have
no need for the extra functions ... but someone wrote them, someone might like them
and I figure offering an idea (however stupid - heck of got so many ;-)) can't hurt
(anything apart from my meager reputation)
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
setinclude_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
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
setinclude_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.
Short history lesson:
The reason for set_include_path() is that many shared hosters disable
ini_set(), yet many libraries/apps depend on users being able to
control their include path.
regards,
Lukas
Lukas Kahwe Smith wrote:
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.Short history lesson:
The reason forset_include_path()is that many shared hosters disable
ini_set(), yet many libraries/apps depend on users being able to control
their include path.
Fair enough. I think I feel pretty lucky that I've never had to operate in
such environments ...
On the other hand I feel unqualified taking a position here either then :)
thanks,
- Markus
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
setinclude_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
Lars Strojny wrote:
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.The current patch is in a bit hacky state, as I have my doubts whether
storing the include paths as a string is a good idea. I want to gain
some feedback for this addition first before I invest more work on it.[1] http://lars.schokokeks.org/php/include_path_modifiers-1.diff
-1 from me, it doesn't reduce code size, and speed is not a huge issue
since it is likely to be called once per script, maximum.
Greg
Hi,
Am Mittwoch, den 13.02.2008, 16:47 +0100 schrieb Lars Strojny:
[...]
The current patch is in a bit hacky state, as I have my doubts whether
storing the include paths as a string is a good idea. I want to gain
some feedback for this addition first before I invest more work on it.
Just for the record, there is an improved version of this patch. It
returns now false if snprintf() could not format the string properly.
See
http://lars.schokokeks.org/php/include_path_modifiers-2.diff for
details.
However I have the feeling that actually only a few see this patch as an
improvement, so I we are not going to add this anyway.
cu, Lars
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is
what
is done most of the time.The current patch is in a bit hacky state, as I have my doubts whether
storing the include paths as a string is a good idea. I want to gain
some feedback for this addition first before I invest more work on it.[1] http://lars.schokokeks.org/php/include_path_modifiers-1.diff
Seems kinda silly, really, since one can just do:
set_include_path("foo:" . include_path());
set_include_path(include_path() . ":bar");
Okay, you need to use PATH_SEPARATOR and maybe you'd want to be sure
you're not adding the same path twice in a really fancy version...
But even that wouldn't be 100% with symlinks or other funkiness like
using "/foo/bar//baz/"...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?