On Wed, 12 Dec 2018 at 00:29, Levi Morrison <morrison.l...@gmail.com> wrote: > > On Tue, Dec 11, 2018 at 2:01 PM Peter Kokot <peterko...@gmail.com> wrote: > > > > On Tue, 11 Dec 2018 at 21:33, Levi Morrison <morrison.l...@gmail.com> wrote: > > > > > > On Tue, Dec 11, 2018 at 8:16 AM Derick Rethans <der...@php.net> wrote: > > > > > > > > On Tue, 11 Dec 2018, Christoph M. Becker wrote: > > > > > > > > > On 11.12.2018 at 13:42, Kalle Sommer Nielsen wrote: > > > > > > > > > > > Den man. 10. dec. 2018 kl. 23.01 skrev Christoph M. Becker > > > > > > <cmbecke...@gmx.de>: > > > > > > > > > > > >> It seems to me that it might be valuable to agree on a common > > > > > >> coding standard for *all* php.net PHP scripts, not only the web > > > > > >> related ones, but also the helper scripts in php-src, etc. > > > > > >> Therefore, it might be appropriate to discuss this on internals@. > > > > > >> Perhaps we should even have an RFC about this. > > > > > > > > > > > > Perhaps, but I think its still a unified agreement from way back to > > > > > > use PEAR CS for any PHP at php.net, what I think we should do is to > > > > > > better advertise it for new contributors (I think opening the > > > > > > discussion about a potential new CS is gonna be way too political > > > > > > for practical no reason). > > > > > > > > > > PEAR CS has been fine, but it seems to me that it's pre PHP 5.3, if > > > > > not even pre PHP 5.0. Consider, for instance, the naming > > > > > conventions[1], which completely ignore the possibility of > > > > > namespacing. And they mandate: “Private class members are preceded by > > > > > a single underscore.” Furthermore, the header comment blocks[2] are > > > > > too picky (and don't even support PHP 7[3]). > > > > > > > > > > If we want to go with PEAR CS, we should point out exceptions to these > > > > > rules, and perhaps amend the PEAR CS slightly for our purposes. > > > > > > > > Sorry, but PEAR is from 1999. The PHP world has moved on now, and it > > > > makes perfect sense to use common PHP development practises. This > > > > includes not reinventing the wheel by (re-)using Composer packages, and > > > > using a CS standard that people currently writing PHP code are familiar > > > > with. And that means using PSR-x. We'd want to encourage new people > > > > stepping up and helping out like Peter is doing, and using modern > > > > practises is going to help with that. People like shiny, and not 20 year > > > > old legacy apps. > > > > > > > > cheers, > > > > Derick > > > > > > > > -- > > > > https://derickrethans.nl | https://xdebug.org | https://dram.io > > > > Like Xdebug? Consider a donation: https://xdebug.org/donate.php, > > > > or become my Patron: https://www.patreon.com/derickr > > > > twitter: @derickr and @xdebug > > > > > > > > -- > > > > PHP Webmaster List Mailing List (http://www.php.net/) > > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > First, thanks Peter for actually spending some time on these projects. > > > We all know they need more attention. > > > > > > Second, the vast majority of the changes I've seen made are changes > > > for change's sake. These are likely to cause bugs which is a step in > > > the wrong direction. I would much prefer that we do not do this. Can > > > we please make these changes while we are also looking into bug fixes > > > or enhancements? > > > > > > Third, my opinion is that PHP.net should not be using an auto-loader. > > > I've seen tons of projects that have classes that contain only static > > > methods, and they do this because now it can be easily autoloaded. > > > This is backwards -- the design should dictate how code is loaded, not > > > the other way around. Therefore, it does not matter if the site uses > > > PSR-4 or not. > > > > > > Fourth, I will probably not participate much more in this discussion. > > > It's prone to arguments and debates which I just don't have time for > > > right now. > > > > > > Good luck, Peter, and I hope everyone has enjoyable end-of-year holidays. > > > > A lack of autoloader means also lack of OOP then. Back to complete > > functional programming for bugs.php.net and pecl.php.net? I'm not sure > > I even know how to code like that anymore :) > > > > -- > > Peter Kokot > > No, lack of an auto-loader does not mean a lack of object oriented > programming. It just means that setup code is intentional, and not > loaded ad-hoc throughout the runtime of a program. > > -- > PHP Webmaster List Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >
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? - 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 And front controller (or any file) then includes the prepend.php file: require_once __DIR__.'/../includes.php'; use App\Foo; $foo = new Foo(); -- Peter Kokot -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php