why a class

<?php

define( "DOC_ROOT", $_SERVER['DOCUMENT_ROOT'] );
define( "APP_PATH", dirname($_SERVER['PHP_SELF']) );

echo "os: " . PHP_OS . "<br/>" . PHP_EOL;
echo "root: " . DOC_ROOT . "<br/>" . PHP_EOL;
echo "app_path: " . APP_PATH . "<br/>" . PHP_EOL;
echo "inc_path: " . ini_get("include_path") . "<br/>" . PHP_EOL;

?>

I shall address your concern:

First, not everyone has access to the PHP configurations and settings sprinkled among the php.ini files or webserver equivalents under which they are running their scripts. Because of this certain inconsistencies arise:

Take for instance DOCUMENT_ROOT. On some IIS systems it is NOT PRESENT, and so it must be constructed. Sure, you can add it on at least Windows XP Service Pack 2 by right-clicking on "My Computer" -> Properties -> Advanced, accessing the system variables, and typing in 'DOCUMENT_ROOT' in the value field. Or you can get it back by having PHP run as ISAPI, however like I said, not everyone has those options available.

This class doesn't even TAKE into account (yet) the fact that under some configurations of PHP under Windows XP Service Pack 2 and IIS, $_SERVER(...) returns inconsistent paths using forward slash '/' as the separator. The forward slash appears particularly on PHP_SELF, and SCRIPT_NAME, but not (as in, it's a backward slash '\') with __FILE__, SCRIPT_FILENAME, and DOCUMENT_ROOT, the last one depending of course on what methods you previously used to obtain it in the first place. As well, if the name of the last directory in the document root in these cases includes a space then other popular / advertised methods of 'decoding/obtaining' document root under these conditions fails, whereas the ones used in Filebase shouldn't.

In Windows 2000, running IIS an dPHP 4.3.10, $_SERVER['SCRIPT_NAME'] doesn't exist, however $_SERVER['SCRIPT_FILENAME'] does and appears to provide the same information, the the included logic.

Some web hosts implement php as a CGI in such a way that they can turn it on or off for each virtual domain. Because of this some $_SERVER and $_ENV variable values may be incorrect for documents in subdirectory subdomains. I hope developers might also tinker with my class to suit their needs in such cases.

Unfortunately chris' included function is not full proof. It won't work with virtual folders or in any situation where the folder in the url doesn't map to a real folder on the disk (he mentions rewrites). This might be changed then in a future version.

There's countless more obscure and strange occurrences, such as say Xitami. Running Xitami in Windows 2000 and PHP 4.3.7, neither PHP_SELF nor SCRIPT_FILENAME is available, however SCRIPT_NAME is available.

Secondly, I made it a class due to a design decision. Simply declaring constants leaves us with no logic to discern those constants, particularly if those constants don't exist in the first place, as pointed out above. I could have just as easily made a file with a bunch of functons that gets executed as a 'header' every time a script runs, but that would leave the function names laying about possibly interfering with other project functions in the global namespace. Thus, all things considered, I decided encapsulation into a namespace was a good idea. The idea that it didn't have to be instantiated appealed to me, so I made it so.

It is my goal to create solutions in PHP that are highly cross-platform compatible. Believe it or not PHP is run on many different types of machines with all sorts of configurations, and not just on UNIX machines running Apache 1/2.x. I appreciate constructive criticism and calls for additional features or code trimming, but I appreciate even more well tempered hubris as opposed to unresearched and inconsiderate dismissals.

Good day,
Asher

echo "inc_path: " . ini_get("include_path") . "<br/>" . PHP_EOL;

Also to note, this line is WRONG and does NOT accomplish the same thing as my class. My class will return as an example:

/usr/local/Zend/Apache/htdocs/phpapp/

Where as yours will possibly return anything from:

.;/path/to/php/pear

to:

.;/path/to/php/pear;/path/to/something/else;/dir1/dir2/dir3;~oper/dir5/

Which is NOT the same thing.