Making PEAR2 Portable

I've been thinking about this thread about how PEAR2 might handle dependences so as to allow PEAR2 packages to be embedded within self-contained unzip and go applications. I think this goal is worth considering. Comments and proposals: 1) PEAR 2 packages can only work as part of a standard PEAR2 directory tree. All PEAR 2 packages will depend on other PEAR packages. If nothing else, they will all depend on the PEAR2_Exception class. The references among files in a PEAR installation all rely on a standard directory structure. The only way to embed a PEAR package within another application that we should try to enable should thus be inclusion of a stripped down version of the standard PEAR2 directory tree as a subdirectory of the application. The minimally functional directory tree would include the Exception class and PEAR2::Autoload function, and I'm not sure what else. 2) For this kind of embedding to work, references among PEAR2 classes and files, within the PEAR2 directory tree, could not rely at all on include_path. The directory tree would have to be entirely portable - if you move the whole tree, everying should still work correctly. Inclusion of PEAR2 files into user code outside this tree might or might not depend on the include_path containing the root PEAR2 directory - that would be up to the user. 3) If the PEAR2_Autoload function becomes the standard way to load PEAR2 classes, perhaps this function should thus define paths to class files using something like: $PEAR2_root = __FILE__ . '/..'; $full_path = $PEAR2_root . str_replace('_', '/', $class) . '.php' The use of a relative reference to __FILE__ guarantees that the Autoloader constructs absolute paths correctly, without any reliance on include_path. It looks to me like the current version of PEAR2::Autoload() in svn assumes that the include_path contains the PEAR2 root. 4) To help load data, or other PEAR2 files that aren't class definition files, PEAR2 should also provide a standard way to obtain the root directory of the current PEAR installation. This could be implemented as either a data member or the return value of a method of a PEAR2 class, so it can be found by the PEAR2::Autoload function. This path could also be determined using a relative reference to __FILE__ in code with a known location in the PEAR2 directory tree. 5) Perhaps PEAR2 should simply provide a somewhat simpler PEAR::AutoLoad function than the one now in svn, and then give users clear instructions of several ways to make sure it gets used as the (or a) autoload function. Instructions could be given in the manul of several ways to accomplish this: i) For beginners: Instruct the them to add the following line to user code: require 'FullPathto/PEAR2/__autload.php'; The PEAR2/__autoload.php file file would then contain a one-line implementation of the magic __autoload() function that calls the custom PEAR2::autoload() function internally: <?php function __autoload($class) { return PEAR2_Autoload($class); } ?> Perhaps I'm missing something, but don't see the point of having the PEAR2_Autoload() function try to define the magic __autoload() function internally, as done in the current svn implementation. If the PEAR2_Autoload function will normally be called only from within an __autoload() function, then an __autoload() function must necessarily be defined before PEAR2_Autoload() is called. ii) For user that prefer to define a custom __autoload function: Give examples of how to call the PEAR2::autoload() function from within a more complicated user defined __autoload() function. iii) For a user that prefers spl_autoload_register : Explain how to register the PEAR2::Autoload function. It would be up to the user to use the spl autoload stack in a way that avoids conflicts between autoloader implementations used by different libraries or packages. This way, PEAR2 supports __autoload() and spl_autoload_register equally well. If this solution were accepted, you would also remove the code in the current PEAR2_Autoload that tries to reset the include_path - the whole goal would be to make the include_path irrelevant for the functioning of the autoloader. Comments? Anything obviously wrong? -David ---------------------------------------------------------------------------

|  David Morse				      email: morse@cems.umn.edu   |
|  Dept. of Chemical Eng. & Materials Sci.    phone: (612)625-0167        |
|  University of Minnesota		      fax:   (612)626-1686        |

| 421 Washington Ave. S.E. | | Minneapolis, MN 55455 | ---------------------------------------------------------------------------