Re: dirname(__FILE__)

Most of these problems can be avoided by using a php-level class loader and adding a level of indirection to things. The catch there is that it can be a pain trying to integrate this method with existing frameworks like PEAR, unless you plan ahead. A loader can keep track of which files have been included already and second/third/n-th calls to include the same package are simply ignored. With mine (http://testing.simian.ca/saf/docs/index.php?class=Loader&extension=php), I also use the idea of namespaces, which represent different base paths for including documents. Then I can simply include away using more of a Java-like syntax, and not have to worry about resolution. The drawback is the performance hit, but honestly it's worth it for me so that I can avoid issues like these. Here's all I have to do now to get on with coding: <?php include_once ('saf/init.php'); // init.php sets SAF_DIR to be dirname(__FILE__) then defines a $loader object // with the namespace 'saf' pointing to that $loader->import ('saf.CGI'); $loader->import ('saf.Ext.PEAR.XML_RPC.RPC'); $cgi = new CGI; $client = new XML_RPC_Client (...); // etc. ?> The performance hit is when I translate saf.Ext.PEAR.XML_RPC.RPC to saf/lib/Ext/PEAR/XML_RPC/RPC.php, but you can see how that doesn't require too much work (str_replace). You can download it at www.simian.ca to check it out further, and everyone's free to use it (PHP license). I've also added some features to my DocReader package that will allow alternate parsers and output writers to be adapted to it, so Brent Cook's earlier interest in it becoming part of PEAR is a little more possible. To be compatible with existing PHP documentation formats, parsers would have to be adapted (not too hard), then DocReader can read the new formats as long as a DocReader directive is on some comment line in the file. These take the form of: //!docreader (version="2.0", format="XML", output="XML") I envision formats such as "PHPDoc", "Tokenizer" (something based on that extension), "SLiP" (I like this little markup language, simple and effective), and potentially many others. Output writers can also make this publishable to multiple formats. If anyone is interested in helping out with these (I don't have time quite yet as I'm in the middle of preparing a new product release, but the existing ones are well documented), I would love to be able to contribute my code to PEAR. Lux On Thursday, October 24, 2002, at 06:25 PM, Markus Wolff wrote:

On Fri, 25 Oct 2002 00:38:44 +0200 Wolfram Kriesing <lists@kriesing.de> wrote:

imagine you have an old PEAR::someClass in tree one, which has an old API but in tree two the API of this class is the newest but since the application that works with the old API, so to say tree one is so huge, approved and stable that you dont want to or cant change the entire application, you need to have exactly this setup as dirname(__FILE__) would provide. i came across this problem a lot of times. and dirname(__FILE__) would solve it! or do i not understand something here?

The catch is: What happens when you need to combine applications or just application components that all rely to some extent on PEAR classes - some providing their own copy of a certain class for stability / BC assurance or whatever reasons, and some are using the standard PEAR installation. In this case, you could end up with one file including: include_once('/path/to/my/app/HTML/IT.php'); and another including: include_once('HTML/IT.php'); PHP would treat these as two different paths (even if both paths would end up to be the same when you resolve the include_path), so what you´d get is a double class declaration which would cause the parser to throw errors. On a side note and completely off topic: Is it normal that I can in fact declare functions with the same name multiple times as long as they´re contained in a class, even if it´s the same class? I noticed that PHP will not throw any error, but use the last function that was declared instead, overwriting the other ones. When I do this outside of a class the parser exits with an error - and that´s the way it should be, IMHO. Or is it just a bug in PHP? Regards, Markus --Markus Wolff <wolff@21st.de> -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- John Luxford Simian Systems _______________________ phone : 204.946.5955 email : lux@simian.ca web : www.simian.ca _______________________ web content management application development consulting and training