On Wed, Nov 9, 2011 at 5:16 PM, Rafael Dohms <lis...@rafaeldohms.com.br> wrote: > On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> > You sort of prove my point here, as you actually have your own > autoloader, which in case you are PSR compliant, you would not need, > you can still use your bootstrap but no longer implement the class. > Also bootstrapping is not a solution for smaller libraries that > include one or 2 classes, having to code an autoloader for everything > is redundant. And frankly having to make sure you do requires to get > the loaders is something i would rather get rid of. The day i can code > a whole application without a single require in it will be a blast. I am not PSR compliant in either autoloader implementation or class implementation. The reason is that over time I have needed (and removed the need, but may in the future) need to use a class name as a reserved word. Something like XOR (which is a real example). My way of solving that was to name the class X_OR to avoid the fatal syntax error. But I don't want it stored in /foo/bar/x/or.php. Which would make absolutely no semantic sense. So I went with the alternative of /foo/bar/x_or.php (which to me makes perfect sense). And the autoloader I built is trivial. In fact, I don't use it everywhere (out of need). In fact, I can replicate it in 10 pretty lines of code (+1 for the comment): https://github.com/ircmaxell/PHP-CryptLib/blob/master/test/bootstrap.php#L33 spl_autoload_register(function ($class) { $nslen = strlen(__NAMESPACE__); if (substr($class, 0, $nslen) == __NAMESPACE__) { $path = substr(str_replace('\\', '/', $class), $nslen); $path = __DIR__ . $path . '.php'; if (file_exists($path)) { require $path; } } }); > This depends on the size of your library, bootstrapping might not be a > requirement, and from what i see around its actually used very little. > Anything needed is attached to your application or is done in the > construct methods. The point is not that it's not possible, the point is that I have to worry about it. I need to look for it in docs, or when reading about it. The onus is put on the user to figure that out. Whereas if I provide a bootstrap file, all I need to communicate is "just require that bootstrap file, and today and for all time forward you'll be fine". If you don't, and your needs change over time (due to feature additions, etc), the way you include libraries can change. Remember, including a library isn't just about defining an autoloader for it... > Libraries can be more the collections of classes, or they can be just > collection of classes. Either way my comment was directed to both > cases. But your comment is only applicable to class-only libraries. Otherwise defining an autoloader is quite simply not enough. You would then need to include the base functions/definition files. Whereas if you used a bootstrap file, it's abstracted away from you. > Bootstrapping and autoloading are two parts of a process, having one > done better does not exclude having the other in your library. > > So a see bootstrapping as a form of configuration and preparation, > autoloading is merely a step that may or may not be in this. I agree that bootstrapping and autoloading are distinct parts. But you're (by you, I mean most of the proponents of this RFC on this list) playing it off like they are the same. A big rationale behind including this is so that you can just distribute libraries and not have to worry about bootstraping or setting up. But you do need to worry about it. I'd MUCH rather see every single library include that 10 line closure than the maintainability nightmare of upgrading a library to have mysterious things break because they changed the initialization process on me. And that doesn't even consider the fact that including this in core will 100% solidify the behavior for the foreseeable future. So if a limitation or shortcoming is found (say with the introduction of traits, or with a 5.5 or 6.0 feature), the implementation is still stuck here for BC reasons. Leave it in userland. Pear has done that for 12 years. Provide a common implementation that gets installed with PEAR (or pyrus) and then just require that as a dependency. It's worked this far, so why such a push to change it...? Additionally, take a look at Python. Python makes including a library *dirt* simple. Why? Is it because it provides you with an autoloader? Not at all (It's import method is used instead of an autoloader, but it's distinctly different in both concept and function). But it's also because it provides a transparent bootstrap (the weird __init__.py file). Loading classes is only half the battle. Others have solved this problem, don't ignore what they have done... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
