Hi, @RDohms
What you said is pretty valid. If you're not going to use it, you vote against it? You may not use it, but many others can. It's a true state. @Anthony I already heard your points many times. I know you're against it. I also know the voting should be reset, but before the reset, I wonder if we can at least keep some good conversation abut possible improvements instead of keep your opinion of being against it. Your vote is only one, like mine, but if it gets approved, are you satisfied with I purposed? If not, what are the improvement points? That's what I want to hear. @Internals I see many people supporting my idea, even after telling everyone after my RFC update to re-validate their votes. Some people have changed, like Peter Cowburn and I don't blame him. He is right. We should make it stable and then vote for it. My wish is that we should really reset and re-open the voting stage, but I want to make the RFC as consistent as possible. It looks like it's getting impossible to have an average talk on this mailing list due to the fact that people want to question about the minimum usage instead of helping me out to consolidate it to then allow people to give their opinions. This attitude only makes me lose a lot of time answering questions instead of focusing on actual RFC stability. I want to propose something stable, I do not want to be pressured about should the RFC exist or not. It only delays the real voting results. What I can do to address this? Thanks, On Wed, Nov 9, 2011 at 11:07 PM, Rafael Dohms <lis...@rafaeldohms.com.br> wrote: > 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 > > -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
