Re: "Namespace polution" in includes

On Thu, 2002-01-17 at 23:31, Sebastian Delmont wrote: > One thing I really don't like about the existing PEAR standards is the way > it poludes the include path. > > Please correct me if I'm wrong, since I don't have much experience using > PEAR. > > Currently, PEAR uses an "installation dir" where it places all it's files > and directories (PHP's "lib" dir, for example), and assumes that directory > is included on the "include_path". > > So, if I want to use the "DB" module, I have to do > require 'DB.php'; > And if I want to use the "Mail/sendmail" module, > require 'Mail/sendmail.php'; > > But what happens if, for some reason, I already had an "Mail" directory on > my website, with a "sendmail.php" page inside it. And those files were > completely unrelated to PEAR... those are "regular pages", to say something. > Well, depending on my current include_path, I will not be able to use the > PEAR Mail/sendmail module. And the bigger PEAR gets, the worse this problem > becomes, since there will be many more filenames that can collide. Well, simply remove "." from your include path and do "require './file.php'" where needed then. > Currently, I have two choices to overcome this problem. Put PEAR as the > first item on my include_path, but this means I can't include my own files > if they collide with PEAR names. Or I can put PEAR as the last item on my > include_path, but if I pick the wrong name for my files, then I can't use > some PEAR modules. > > Either case means I have to be careful about how I name my files and > directories. But even then I can get in trouble if I get a new PEAR module, > or upgrade PHP, since it can contain newer files I didn't take into account > when creating my site. > > Simply put, placing all PEAR files directly "on the top" of the include_path > is a big mistake. > > I see two solutions that can even be used in parallel: > > - place PEAR inside a directory so includes would look like > require 'PEAR/HTTP/Compress.php'; > > - Add some specialized mechanism to PHP for PEAR includes like: > require_pear 'HTTP/Compress.php'; > or > require <HTTP/Compress.php>; > or > require 'pear:HTTP/Compress.php'; > > Again, I'm coming late to PEAR, and this might have been discussed before. > But unless I'm terribly wrong, this is a serious issue that has to be > solved. > > Right now, I can't use PEAR directly because of this problem. I have > resorted to the "PEAR subdirectory" solution, and modified all modules that > I needed to use to use the "longer" include path. Originally, I intended for PHP to provide a "use" statement for loading PEAR code. Zend's current implementation of "use" is currently use-less, and ready to be reviewed in ZE2/PHP 5. What I have in mind is just like Perl: use HTML::Form; // or maybe PEAR::HTML::Form I understand your problem, but this is not an oversight. The only real danger is if the same file path exists in the pear include dir and some other include dir. In the cases where this occurs, you can get around it. If you don't disover it during development, you're not testing your code well enough and I can't feel sorry for you. :-) This could become a problem for more people if PHP itself comes with a lot of pear stuff that is updated like you mention, but it won't do that for much longer. - Stig