Re: Rethink CS for require_once?

Lukas Smith wrote:

maybe I still dont get it but what if a package requires DB and the users code also requires DB. So the users does: require 'foo/bar/DB.php';

No, the user would do require_once 'DB.php';

then he does: require 'foo/lala/DB/NestedSet.php';

and require_once 'DB/NestedSet.php';

NestedSet will also load DB.php but relative to the foo/lala path. So again unless we do a class_exists() before any call inside PEAR that loads another class we hit a brick wall. Actually even worse DB.php is a public file so NestedSet should not use dirname(__FILE__) according to your argument!(?)

In addition, DB is not an internal file to DB/NestedSet - remember, in order to access DB.php from DB/NestedSet.php, NestedSet.php would need one of these two: require_once dirname(__FILE__) . '../DB.php'; require_once dirname(dirname(__FILE__)) . 'DB.php'; both of which are not allowed. Perhaps a better way of defining the change I wish to make is to define it in terms of patterns. If class X implements a 1-to-many pattern like a command pattern (i.e. PEAR_Command), or a factory pattern, and the user is expected to never instantiate the objects directly, then require_once dirname(__FILE__) should be used. In addition, if possible, the code should be loaded in a method (factory, registerCommands), and if possible a check to see if the class exists should be performed before inclusion to allow more flexibility. In addition, providing the ability to specify an inclusion path (a la registerCommands) is a good idea for flexibility. I do *not* want to: 1) start seeing dirname() used for includes all over the place 2) ever see dirname() used to include a PEAR package in another package or user script 3) fix a small problem by ruining what is already working great. 4) force ANY BC breakage over this with existing scripts. This means DB is out. Greg