Den ons. 12. dec. 2018 kl. 00.56 skrev Peter Kokot <peterko...@gmail.com>: > Is there any existing example currently used somewhere? I'm not sure I > fully understand this but there might be something on this. With this, > use statements are not utilized I assume and it goes a bit away from > modern OOP coding practices where each file will still need to have > require_once statements for every required class. Yes? > > Would code look nicer or more complicated than this example?
Well conceptionally the same could be said about a long list of "use X\Y\Z;" vs a require_once statement. I mean sure an autoloader is convinent but it also depends on the actual OOP usage (see below comments for example) > - PSR-4 compliant Autoloader class: > https://github.com/php/web-bugs/blob/master/src/Autoloader.php > - Requiring a single auoloader on a single place in the app (this is > dual loader because of lack of Composer in production): > https://github.com/php/web-bugs/blob/master/include/prepend.php Well they would look just about the same, because what essentially being done is to separate the small bits and pieces from the prepend script into multiple files is how I understand the argument here. I mean sure the prepend script is not pretty, but its a bootstraper. The database class improvements[1] should be straight PDO for the most part: - Passing the statement class should be done with the other set of $options - Instead of implementing methods like queryAll(), the statement fetch methods etc, the code using it should have been updated instead since we are not using MDB2 anymore anyway, so no need to emulate that naming - The statement execute method chaining is nice but again the code should be just updated to reflect PDO - The PDO quote method is a bit tricker, but instead a simple procedural function could be implemented to wrap around it in 3 lines, which would fit functions.php as database access is pretty much used on every page in www/ - Only loaded once in the bootstraper and it is on pretty much every request (because of the authentication check for the navigational links if you are logged in) Similar to what Levi stated in a mail earlier, many projects just implement classes with static methods because it can be easily autoloaded. Many of these classes just implement "static" methods for the sake of autoloading (or so it seems)[2], like: - \App\Repository\ObsoletePatchRepository - Have a constructor to shave off a single argument for two methods - \App\Repository\PackageRepository - Same as above (array keys for the constant array is even redudant) - \App\Repository\PatchRepository - Same for a database handle, it uses a global constant to set a constant value of a property for a private method thats only called once in a non loop - \App\Repository\PullRequestRepository - Same for a dabase handle (Besides I find the "Repository" suffix odd considering they are all in the "\App\Repository" namespace anyway, but its irrelevant) I didn't look too much at the other classes. I get abstracting some things to make it more flawless, is good. The uploading API in PHP is kinda interesting to the the least, but we only really allow uploads in one place (patches), but isn't 200+ lines of abstraction for one place to upload files, including special methods purely for testing, a bit overkill? [1] https://git.php.net/?p=web/bugs.git;a=commit;h=73062503a65bfa62d5f2f365ee99269225580bb9 [2] https://git.php.net/?p=web/bugs.git;a=tree;f=src;h=7b80bef6e77759c469295827e920d92b4216f87d;hb=HEAD -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
