Re: Relativ Includes

On Thu, 2002-10-31 at 16:27, Wolfram Kriesing wrote: > Pierre-Alain Joye wrote: > > On Thu, 31 Oct 2002 15:46:03 +0100 > > "Lukas Smith" <smith@dybnet.de> wrote: > > > > > >>(posted this to pear-general by mistake) > >> > >>Hi, > >> > >>well PEAR still has a serious problem imho with the issues we thought > >>we could solve with dirname(__FILE__): > >> > > > > > > ssb response :-) : > > <ssb> > > > > There are two problems that need fixing here: being able to run tests > > from within a development tree, and using PEAR on systems where you > > can't modify include_path. We have to deal with these, but > > dirname(__FILE__) will cause more problems than it solves. > > > > Consider this a veto. :-) > > </ssb> > > here i come again, with a response i also wrote as answer to Stig's veto! > > <again> > but i think that is what is needed, if i have 2 PEAR installations > with different versions of the files, i also just want tree one to > depend on the files in tree one, not on the files in tree two. that's > why i have 2 installations of PEAR. at least that's what i would need. > > example: > 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? > </again> I think we're getting ourselves into way too deep water here. We simply can not support every single configuration people can think of, especially not at the expense of all the extra hassle and complexity for all packages. dirname(__FILE__) may solve your specific problem, but it will break the whole logic of include_once & require_once. Let me give an simple example: Let's say we have two trees: /usr/local/lib/php (1) and /home/joe/lib/php (2). In tree 1, Foo.php requires PEAR.php, and includes it with dirname(__FILE__)."/PEAR.php"; In tree 2, Bar.php requires PEAR.php and includes it the same way. This will of course break, since when loading Bar.php you'll get redefinition errors from /home/joe/lib/php/PEAR.php. Include_once and require_once were added to PHP to solve exactly this problem. On top of this, PEAR has a standard way of mapping class names to includes, in a _single_ hierarchy. The side-effect of being able to use dirname(__FILE__) to solve your specific problem is that you break this system. Having two install trees that don't overlap may work too, having two that overlap slightly may even work on good days, but I don't think we should bend over backwards to support that. I'm open to discussing other ways to solve problems such as yours, but changing the general way files are included is not how it should be done. We can provide an interface to the *_once internal hashes or something like that instead. I think we should focus on solving two problems _first_: 1. Running tests without installing first (solved with package source directory structure) 2. Using your own pear install with ini_set() disabled and no access to web server config ala .htaccess. - Stig -- Stig Sæther Bakken, Fast Search & Transfer ASA, Trondheim, Norway http://pear.php.net/wishlist.php/ssb