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
Quite a lot of different things are being discussed here. I'll see if I can address them all in the near future or one by one... I just wanted to add some more logical Composer pros (without any dep at all): - required PHP extensions are listed in the composer.json - required PHP version is listed in the composer.json - project meta data is listed in the composer.json I assume that suggesting things like dependency injection container (DIC) or a template engine (in PHP style, not something reinvented and not using Twig/Blade syntax) to split presentation level with XSS dangers on every step and business logic a bit would cause similar galactic level conflicts? Otherwise I appreciate every single feedback actually here. It is quite welcome to hear something at least than not hear anything :) -- Peter Kokot -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
