PHP PEAR Questions and Answers - Re: [PEAR-QA] dirname(__FILE_

Author

Re: [PEAR-QA] dirname(__FILE__)

Justin Patrin

2005-09-21, 3:55 am

On 9/20/05, Markus Albe <malbe@adinet.com.uy> wrote:
> Hi everybody,
>=20
> I'm new to the list and I haven't had time to check if this was already
> discussed:
>=20
> Why not make mandatory the use of "dirname(__FILE__)" prepended to
> includes of other PEAR libraries?
>=20
> Why? To avoid problems with dependencies on servers that don't have PEAR
> installed or that don't have the PEAR path in the include path (I know
> this can be easily added in a common file, but that makes PEAR libraries
> that depend on other PEAR packages less "drop-in'ish", because it relays
> on the assumption that the system where the package is to be used
> already has a file common to all scripts... Also the .htaccess solution
> isn't great, and it costs apache quite a few bytes of extra memory...:-\)
>=20
> Let's take HTML_Page2 as an example, it depends on HTML_Common.
> My dir structure looks like:
>=20
> /var/www/project/bin /* where my scripts are located */
> /var/www/project/lib/PEAR /* where I uploaded PEAR */
>=20
> If the PEAR path is not set in the include path, and I include
> HTML_Page2 from a script in the "bin" dir like
> "include_once dirname(__FILE__).'/../lib/PEAR/HTML/Page2.php';"
> PHP won't be able to find HTML/Common.php when HTML_Page2 tries to
> include it like "require_once 'HTML/Common.php';".
> If instead it required the file like
> "require_once dirname(__FILE__).'../HTML/Common.php';" it won't fail...
> Since file paths must match class names, it's not so hard to determine
> the number of '..' needed, and it could be even automated somehow (I'm
> sure we can come up with some simple method for it)
>=20
> I know it may not look so refined as the current technique does, but so
> far this is the only way to avoid having to append the PEAR path to the
> include path; I only have to have properly include the lib I want and
> that's all.
>=20
> I haven't tested the performance of this, but I'm using it in all my
> scripts and it doesn't seems to affect at all...(of course there's some
> overhead, but probably PHP also has some overhead for resolving a
> relative path agains the full path this technique provides)
>=20
> Hope to hear from your nice community :)
>=20

Aside from the fact that this solution is less elegant and more
verbose, it really doesn't add any real value. I don't understand why
it's a problem to append the PEAR path to the include path. You say
that a .htaccess causes more memory to be used. Do you have any
numbers on this? How about compared to other methods? I doubt that
using dirname() and multiple ".." for every include is going to be
faster than a properly set include_path. Remember that you can also
set include_path per virtual host or directory from within the Apache
config. So if you have a way of altering the apache config (a nice
admin or a special config file in your directory) you can do it this
way as well.

--=20
Justin Patrin

Martin Jansen

2005-09-22, 3:56 am

On Tue Sep 20, 2005 at 10:3305PM -0700, Justin Patrin wrote:
> On 9/20/05, Markus Albe <malbe@adinet.com.uy> wrote:
>
> Aside from the fact that this solution is less elegant and more
> verbose, it really doesn't add any real value.

Aside from that there is also a performance issue involved: Calling dirname()
involves (IIRC) quite a few realpath() calls behind the scenes, which are
relatively expensive in terms of system performance.

The recently introduced PHP realpath cache should solve this problem to a
certain extent, but dirname() still isn't the best idea for busy
environments.

- Martin

Michael Wallner

2005-09-22, 7:55 am

Hi Martin Jansen, you wrote:

> Aside from that there is also a performance issue involved: Calling dirname()
> involves (IIRC) quite a few realpath() calls behind the scenes, which are
> relatively expensive in terms of system performance.

No, dirname() just does some string processing, but it's sill bad
because of the mentioned flexibility reasons.

Regards,
--
Michael - < mike(@)php.net >

Sponsored Links