On Wed, Nov 9, 2011 at 8:49 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > 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: > > 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). >
That is a problem in itself, as far as I know the final class name does not do this kind of conversion on "_" but this is a naming issue and i personally disgree with the solution, which is beside the point and I will not comment. > 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; > } > } > }); > 10 lines, 1 or 30 is still duplicated code which could be left out and lessen the onus on the developer. > 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... > If i program by PSR (which is nothing out of the ordinary) i do not need to worry about autoloading. If i need to worry about bootstrapping, i'm worried with initializing, not finding and including files. > 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. > Its enough to load the class, what you put in bootstrapping is initializing and i prefer libraries that don't initialize on include, rather that initialize when initialized, that's what factories and contruct methods or init methods are for.. not files that initialize as soon as they are included. > 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... > So initializing has nothing to do with autoloading, furthermore, autoloading should neither do nor trigger anything else other then making the namespace available. I'm not a PSR proposer, nor a framework leader, i'm a simple user who has seen the benefit of the PSR and an autoloader, and what this suggestion could do to library and class developers out there. Its a standard, not everyone has to use it, like so many things in PHP which are not used, but its common ground for most to be able to follow, and that makes my life easier. So we should agree to disagree on this one, cause bootstrapping to me a whole separate thing which does not have to do with autoloading. To your example, does import in python initialize or simply make available? Now if you want to add another layer of bootstrapping with a __init__.php file.. that is something to talk about (i don't like it though), but again.. it does not invalidade the presence of a Standard Loader that would simplify the life of some large % of users and developers. -- Rafael Dohms PHP Evangelist and Community Leader http://www.rafaeldohms.com.br http://www.phpsp.org.br -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
