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

Reply via email to