Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95605 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97808 invoked from network); 3 Sep 2016 19:33:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Sep 2016 19:33:47 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:35389] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/F3-32927-8952BC75 for ; Sat, 03 Sep 2016 15:33:45 -0400 Received: (qmail 20914 invoked by uid 89); 3 Sep 2016 19:33:41 -0000 Received: by simscan 1.3.1 ppid: 20907, pid: 20910, t: 0.0982s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 3 Sep 2016 19:33:41 -0000 To: internals@lists.php.net References: <23ef1cf8-b81e-661d-fdbe-3a4a19713652@lsces.co.uk> <03541CD8-0001-4CB7-A8C6-9B931C3C44EE@gmail.com> <29848e09-2728-6960-4128-61d4c55d949f@lsces.co.uk> Message-ID: <628e28ae-ec5d-969f-40dd-cf1376407eb1@lsces.co.uk> Date: Sat, 3 Sep 2016 20:33:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle From: lester@lsces.co.uk (Lester Caine) On 03/09/16 16:43, Rowan Collins wrote: >> This is perhaps my sticking point. I have a perfectly stable framework >> without the need for any 'autoloader', and a folder structure that >> works. Reworking the whole framework so that it follows the 'vendor' >> rules while still also just working with bog standard require_once in >> the right place is where I keep coming unstuck. > > Right, I remember switching to using an autoloader (long long before > composer existed), and what a relief it was not to have to manage great > lists of require_once everywhere any more. :) I think the only thing we > had to fix was some class names being used as lower-case, when the > filenames that needed including were camel-case. The simplest migration > that occurs to me is "if ( file_exists('vendor/autoload.php') ) { > require_once 'vendor/autoload.php'; } else { /* require all the > individual dependencies as before */ }". The problem with that 'simple migration' is that currently I have nothing in the 'vendor/autoload.php' pot and everything in the 'individual dependencies'. I don't recognise the 'manage great lists of require_once everywhere' simply replacing 'vendor/autoload.php' with '../kernel/setup_inc.php' to load the framework. Yes the framework is something of a maze of functions and files, but it only loads a class when it needs it, and skips those it does not need. 15+ years of development starting back in PHP4 days. It's reworking 50+ major packages, pulling out the few files that make up the classes and repackaging them in 'vendor' format, while still having smarty plugins, templates, modules, admin tools and the like and managing just what tools a user has access to based on their role when accessing the site. In essence the composer setup is user specific if I am going down that path, and while making everything available and then not allowing access may be the modern way, only loading the sub-set of packages that the current job needs seems a lot faster to me. And if the user does not have access rights at all we only get as far as loading the access control functions, and throw an error page back. I do have a few third party elements. Smarty is now 'composer loadable', but ADOdb is not and has it's own db selected loader. But smarty is extended with additional local plug-ins so I don't see how there is any gain moving files around the file system rather than keeping them with their intended package. And returning to PEAR, if the relevant package is available, those functions are also switched on, or one falls back to defaults. The installer advises what it can and can't find, gives guidance to installing required tools and advise on optional ones. Something that is easy to do with the PEAR/PECL/dynamic extension system we currently have, but not so easy to manage with composer? A handler can obviously be written to edit the composer setup on the fly, and it's that sort of support I would expect if composer replaces PEAR. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk