# [RFC] prepend_include_path()/append_include_path() - Thread: https://externals.io/message/35448 - Original archive: https://news-web.php.net/php.internals/35448 - Started by Lars Strojny on 2008-02-13T15:47:10+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #35448 — Lars Strojny — 2008-02-13T15:47:10+00:00 URL: https://externals.io/message/35448#35448 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 --- ## #35461 — Pierre Joye — 2008-02-13T22:01:21+00:00 URL: https://externals.io/message/35448#35461 · In reply to: #35448 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 http://blog.thepimp.net | http://www.libgd.org --- ## #35462 — Markus Fischer — 2008-02-13T22:06:57+00:00 URL: https://externals.io/message/35448#35462 · In reply to: #35461 Pierre Joye wrote: > > > […] > > 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 --- ## #35463 — Pierre Joye — 2008-02-13T22:12:46+00:00 URL: https://externals.io/message/35448#35463 · In reply to: #35462 > Pierre Joye wrote: > > […] > > 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 --- ## #35464 — Lars Strojny — 2008-02-13T23:04:47+00:00 URL: https://externals.io/message/35448#35464 · In reply to: #35461 Hi Pierre, Am Mittwoch, den 13.02.2008, 23:01 +0100 schrieb Pierre Joye: [...] > > […] [...] > 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 --- ## #35465 — Lars Strojny — 2008-02-13T23:05:39+00:00 URL: https://externals.io/message/35448#35465 · In reply to: #35463 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 --- ## #35466 — Jochem Maas — 2008-02-13T23:56:49+00:00 URL: https://externals.io/message/35448#35466 · In reply to: #35464 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: > [...] > > […] > [...] > > […] > > Sure? > > > […] > > See: prepend_include_path('/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 --- ## #35468 — Gregory Beaver — 2008-02-14T01:11:31+00:00 URL: https://externals.io/message/35448#35468 · In reply to: #35448 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 --- ## #35470 — Pierre Joye — 2008-02-14T01:47:15+00:00 URL: https://externals.io/message/35448#35470 · In reply to: #35465 > Hi Pierre, > > Am Mittwoch, den 13.02.2008, 23:12 +0100 schrieb Pierre Joye: > [...] > > […] > > So you agree? Thanks :) I don't, it was a joke :) -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35483 — Lars Strojny — 2008-02-14T09:07:56+00:00 URL: https://externals.io/message/35448#35483 · In reply to: #35466 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 *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()). cu, Lars --- ## #35487 — Lukas Kahwe Smith — 2008-02-14T09:12:24+00:00 URL: https://externals.io/message/35448#35487 · In reply to: #35483 > Hi Jochem, > > Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas: > > […] > > 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()). 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 --- ## #35484 — Markus Fischer — 2008-02-14T09:20:13+00:00 URL: https://externals.io/message/35448#35484 · In reply to: #35483 Lars Strojny wrote: > Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas: > > […] > > 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 --- ## #35485 — Lukas Kahwe Smith — 2008-02-14T09:25:09+00:00 URL: https://externals.io/message/35448#35485 · In reply to: #35484 > Lars Strojny wrote: > > […] > > 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 --- ## #35486 — Derick Rethans — 2008-02-14T09:26:38+00:00 URL: https://externals.io/message/35448#35486 · In reply to: #35484 > Lars Strojny wrote: > > […] > > 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 --- ## #35489 — Markus Fischer — 2008-02-14T09:34:07+00:00 URL: https://externals.io/message/35448#35489 · In reply to: #35485 Lukas Kahwe Smith wrote: > > > […] > > 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. 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 --- ## #35491 — Jochem Maas — 2008-02-14T09:57:31+00:00 URL: https://externals.io/message/35448#35491 · In reply to: #35487 Lukas Kahwe Smith schreef: > > > > > […] > > > 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) --- ## #35507 — Lars Strojny — 2008-02-14T13:30:08+00:00 URL: https://externals.io/message/35448#35507 · In reply to: #35448 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 --- ## #35504 — Richard Lynch — 2008-02-14T23:46:33+00:00 URL: https://externals.io/message/35448#35504 · In reply to: #35448 > 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?