This expression – dirname(__FILE__) – is used in a real lot of places. The reason is simple – libraries want to include files relative to library top directory, and do not want to count on include path. And relative include resolution rules in PHP not clear to all, so people prefer to be sure. The downside here is that this expression is dynamic – executed at run-time. Meaning it’s slower and less toolable and also makes a bad habit of putting dynamic things into include (which is not a problem here, since it’s “static dynamic” thing, but still a bad habit).

So why won’t we have constant that would mean dirname(__FILE__)? Something like __FILEDIR__. Would make a lot of code cleaner.

The problem with it of course to make real use in code we should travel back in time to 1996 and add it there πŸ™‚


22 thoughts on “dirname(__FILE__)

  1. __DIR__

    The directory of the file. If used inside an include, the directory of the included file is returned. This is equivalent to dirname(__FILE__). This directory name does not have a trailing slash unless it is the root directory. (Added in PHP 5.3.0.)

  2. I agree with this. Using __FILE__ together with symbolic links is not a good idea. I tried to link most of the WP files in order to easily update several blog sites at once but because __FILE__ will output the “real” filename (and path) instead of the symlink it is not possible without modifying many codes. If any other constant could be used to refer to the base, it would be really handy in this situation. Anyway, I will try WPMU and see what can I do…

  3. Pingback: Do You PHP はてγͺ

  4. Pingback: nothing happens

  5. ..and best (most efficient) way to get name of parent directory of directory etc. etc. is not e.g. playing with substr() function but instead nesting dirname calls like: dirname(dirname(__FILE__)) πŸ™‚

  6. Pingback: Rich Buggy » Blog Archive » dirname(__FILE__)

  7. It’s never too late to include a good idea like this. Eventually PHP 4 and 5 will stop being supported. Let’s get this into 5.2.2 (or 5.3) so that it’s there for 6!! Then people writing new code for PHP 6+ can use it.

  8. An alternative is to do something like the following:

    By doing this, you save the “run-time” cost (which is trivial anyway, but why do things which aren’t needed), it maintains backwards compatibility with PHP4, and requires nothing of anyone else but yourself.

  9. Pingback: developercast.com » Blog Archive » PHP 10.0 Blog: dirname(__FILE__)

  10. Pingback: PHPDeveloper.org

  11. Well, this exactly one because it won’t work on Windows πŸ™‚ But properly fixing the ‘:’ part, still it might be a problem if for example two libraries have files names by the same names – include path could find the wrong one.

  12. This is something that can be easily handled by an opcode optimizer. When a function always returns the same output based on some constant input (e.g. md5(‘foo’) ) that entire expression can be reduced to a simple constant itself (‘acbd18db4cc2f85cedef654fccc4a4d8’ in this case). Extrapolating an absolute path (which __FILE__ always contains) to the result of the dirname() function is just as trivial and just as portable across versions and hosts.

  13. but i dont think thats gonna happen

    Because I don’t necessarily expect any of it to be in PHP 6, 7, 8 and Because I don’t necessarily expect any of it to be in PHP 6, 7, 8 and 9


  14. Great idea and I totally agree..

    I personally tend to always use the latest PHP version all over the place (unless its a x.x.0 version) so for me this would be a great feature..

    either that or make dirname a language construct, which would have the same effect πŸ˜‰ but i dont think thats gonna happen..

  15. If you want to start a poll, I’ll vote for it! πŸ˜€

    Currently I do not use it anymore, but a lot of older scripts contains this “expression”. Maybe it would be no fault to go back to 1996 … although I would be too young O.o

Comments are closed.