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 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
