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'; 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. On Wed, 12 Dec 2018, 04:56 Kalle Sommer Nielsen <ka...@php.net wrote: > 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 >
