On Wed, 12 Dec 2018 at 21:11, Peter Kokot <peterko...@gmail.com> wrote: > > On Wed, 12 Dec 2018 at 11:43, Christoph M. Becker <cmbecke...@gmx.de> wrote: > > > > On 12.12.2018 at 05:32, Kalle Sommer Nielsen wrote: > > > > > Den ons. 12. dec. 2018 kl. 05.23 skrev Peter Kokot <peterko...@gmail.com>: > > >> > > >> Wait... Why do we then even have use statements in PHP if we can always > > >> require_once a class file where needed and we're done with it. Your > > >> explanation of requiring only files from a pool of files sounds very > > >> simple > > >> and even something to go implement it (read undo). However: > > >> > > >> require_once 'User.php'; > > >> require_once 'Repository/User.php'; > > > > > > I think you misunderstood, or perhaps I phrased myself poorly. It's > > > the same clutter in the top of a file is what I meant to make a point > > > about as thats how I read your response initially. > > > > Namespaces and imports (`use`) are not directly related to auto-loading > > vs. manual loading (`require`). > > > > >> PDO wrapper is in need of something better. I didn't want it to refactor > > >> it > > >> yet what it should be for a unit testeable piece of code. > > > > > > But why should there be a wrapper in the first place if we use > > > straight PDO? The wrapper doesn't add anything besides the exception > > > of a better escaping method. If the wrapper is for unit testing, then > > > I still wonder why as its already well tested in php-src. > > > > The PDO wrapper was already there before Peter started extensive work on > > the bug tracker; certainly, as already suggested in the class' doc block > > comment, it could be removed *sometime*. > > > > Let's face it, the bugtracker is (or has been a few weeks ago) legacy > > code, at least according to Michael Feather's definition (“To me, legacy > > code is simply code without tests.”[1]) It's hard to impossible to unit > > test procedural code, so it seems not unreasonable to me to rewrite it > > to something that can be unit tested, if there are resources to do so. > > > > The argument “we shouldn't use an autoloader, since it is often misused > > to load static classes” is moot, since there don't seem to be any static > > classes. The point Sara made a while ago on internals, namely that > > php.net shouldn't use a framework to not endorse any particular > > framework[2] is valid, but in my opinion, that does not necessarily > > apply to Composer and PHPUnit, since both are de-factor standards in the > > PHP community for a long time (and to my knowledge, there are no still > > maintained alternatives). Of course, we could roll our own, but I see > > no point in re-inventing the wheel here. > > > > Anyhow, since these changes are apparenlty controversial, it might be > > sensible to apply them in a feature branch, and to present a “final” > > version as pull-request. On the other hand, I understand that it would > > be very frustrating to spend days on such a pull-request, which is > > finally rejected or even ignored. > > > > [1] Feathers, Michael. Working Effectively with Legacy Code (Robert C. > > Martin Series) (Kindle-Position229). Pearson Education. Kindle-Version. > > [2] <https://externals.io/message/103048#103049> > > > > -- > > Christoph M. Becker
Hello, assuming that we want to at least test some code in the app and install locally some dependency, here is a quick explanation why autoloader matters and is actually required in cases of applications such as bugs.php.net (logins, database access, uploading files and more): https://github.com/petk/autoloading-tutorial 1.) The php-5.2 folder contains what was aimed in this conversation also I think: No namespaces and no autoloading would require to have the most difficult testing and most legacy looking code available. 2.) The "no-autoloader" folder has example with namespaces and no autoloader: - Similar issue with testing code and as soon as library class is required 3.) The "autoloader" folder contains autoloader and namespaces - the testing example is much more simplified and usable than all previous ones Now, if we imagine adding more classes in the application, yes, more complexity comes, but also more flexibility with testing, and using the code across the app. Currently we have functions used, mixing SQL, HTML, and PHP code in same files. Not to mention globals in some functions which is also an issue. Something like this. -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
