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