Re: Why change require_once? A brief explanation of motives

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Greg Beaver wrote: > Hi all, > > [...] > > Finally, setting up include_path has proven again and again to be a > major issue, and not just for beginners, as has been asserted in many > (rather condescending) emails written in response. [...] As many have already said the problem of setting up an include_path is not really existent. It's one line of code with no work behind it. And if someone can't handle then it is very easy to help him. I think easier then with __autoload() or allfiles.php. But with the new approach I have to write an own implementation of __autoload() or search for the dependencies to include them. This shifts the work from the developer to the user (or other developers) which is not a good move I think. > The new coding standards are designed to eliminate these problems all at > once. There are two separate approaches to this: > > Thing 1 > ======= > Eliminate require_once > 1) use class names without loading the files containing them > 2) provide an autoload mechanism (PEAR2_Autoload) Will there be such a class or not? Some say it and others say that there will be no such class. I'm against such a class because it requires on more file to load which we want to prevent. And it makes it slower and more complex then the current solution (require_once 'package.php'). > 3) provide a "it just works" file that can be included to quickly use a > package (allfiles.php) To ensure this file is always present it should be generated by the packager (or installer). This would shift the work away from the developer and also away from the user. But the problem with dependencies is still there. If I have 3 packages and the first depends on the others I have to read the code (or documentation) to find them and include all allfiles.php by hand (and there are more complex dependencies situations). All this has to be done by the user which I think is overcomplicated. > Thing 2 > ======= > Better document what is needed > 1) use a graceful if (!class_exists('name', true)) for reporting missing > dependencies Isn't this slower then require_once? We really need good benchmarks (published) to see what is faster. > 2) make sure all files needed are listed in the comments at the top of > each file > 3) add a README file to each package > > [...] > > #3 means we are never going to have another base class named PEAR2 or > PEAR2_Loader - the inflexibility will make embedding PEAR2 libraries > harder than it is to embed PEAR libraries now. But do we have an PEAR2_Autoload or not? I can't read this from all the replies. > Finally, #4 means we have to allow people to selectively include > portions of a package, which the proposed solution does in fact allow. > > What is really involved for you all? Change you code like so: > > <?php > require_once 'Another/Class.php'; > class Blah extends Another_Class > { > } > ?> > > to this: > > <?php > /** > * This needs the Another_Class package, located at > http://pear.php.net/pear2/Another_Class > */ > class Blah extends Another_Class > { > } > ?> > > note that I made up the URL, I have no idea what it will actually look > like for PEAR2. > > Users would simply need to either use allfiles.php, autoload, or if > performance is an issue, they can do: > > <?php > require '/full/path/to/Another/Class.php'; > require '/full/path/to/Blah.php'; > ?> > > and they are good to go, and can turn off APC stat and have efficiency - > ALL interested parties win, use of PEAR skyrockets, and we get a > crapload of new developers in the process to improve things. But what if this package has also dependencies? Then I would have to search all files for those comments to get them included. Now I can simply do the following and know the class/file will handle everything, which I think is the main aim of PEAR, to move away work from its users. require_once 'Another/Class.php'; And if I want/have to use __autoload() then I must write an own implementation which works with PEAR (and maybe my own implementation). > I am happy to discuss any of the proposals and change them, but please > limit your comments to brief and carefully researched comments, FUD is > extremely discouraging and does not help us solve the problems at hand. > > Thanks, > Greg And people who want the absolute maximum of speed will either not use PEAR (or only extract necessary parts) or can simple remove all require_onces and generate an allfiles.php by themselves. But such maximum speed is not so often necessary. And with the improved version of APC this should be even a smaller problem. I think we should not make all these things too complicated. The require_once solution may not be the best/fastest but as far as I know it's the simplest (if PEAR is not in the include_path it's one additional line and can be easy generated). I think PEAR should use a simple solution for everyone, users and developers and not burden too much work on them. Thanks for your replies, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGnLmiYRX4BO+zMikRChAWAJoCtefi+svTR5/5P8/guTEkY/Uv6QCgk8st hD0S6pJVOEhEvB4zYf6s5W8= =/Ysl -----END PGP SIGNATURE-----