Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error)
To: internals@lists.php.net
References: <CADqTB_gBFM_2yNDQemPs68Fab4Hbd8pGj38a3-HSQ+CRcnDyvA@mail.gmail.com>
 <ee6521f3-123b-83bf-5b7f-b20d0bc4b832@lsces.co.uk>
 <CADqTB_jTGGx=Xvq8vQab2YZoOuuyr7E6a_NWmgaYbARAJPSJ3g@mail.gmail.com>
 <9ccdcfcd-7a1c-42df-c893-398781e1f1d2@lsces.co.uk>
 <CAESVnVoCkp+ZszmigzmNt6+HLqi8pLB2Xi8a4cYM-=01x=rZqw@mail.gmail.com>
Message-ID: <e0ff392d-a343-1d14-3fc9-5e42e25b5c50@lsces.co.uk>
Date: Wed, 10 Aug 2016 09:51:04 +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: <CAESVnVoCkp+ZszmigzmNt6+HLqi8pLB2Xi8a4cYM-=01x=rZqw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Function auto-loading
From: lester@lsces.co.uk (Lester Caine)

On 09/08/16 06:54, Sara Golemon wrote:
> On Mon, Aug 8, 2016 at 9:59 PM, Lester Caine <lester@lsces.co.uk> wrote:
>>> That is, when I'm running the test-suite of my package, the Composer
>>> project is the root folder of that package - but when the package is
>>> being consumed by another project, it's installed in a sub-folder in
>>> that project's "vendor" folder.
>>
>> So Composer IS now the rule rather than some optional extra?
>>
> Yes, the community has decided that for us.  Or at least, Composer is
> a *significant* player in the ecosystem of PHP development.
> require_once() might be fine for NiH applications, but for the
> collaborative world of modern PHP, it's the defacto standard.

Much as PSR also does.
This is probably fine if one is starting a project from scratch, but
with now 15+ years worth of code that does not follow this 'modern
style' it's another barrier to moving code forward. There is nothing
wrong with the code other than newer users done approve of the style of
working :(

>> It is OK
>> for users who only want to load the one application, but when one is
>> running a large number of different packages it's a major hindrance.
>>
> You'll need to back that up with some more detail.  Composer is
> specifically designed to _compose_ through multiple packages and also
> allows for isolation when that sort of blending doesn't make sense.
> Far from a hinderance.

Several packages that I have been trying to update have said that it's
better NOT to use composer if you need to maintain a legacy view in
addition to the newer code. Certainly having to keep different installs
of PHP with different structures does not help the development process.
It's bad enough running PHP5.4, 5.6 and 7 in parallel without also
changing the framework as well.

>> I don't need to know where my Linux install has put the include files ...
>> it takes care of that and then finding the pigging things again is the
>> problem.
>>
> So, autotools and cmake and the like exist for what purpose then?
> Even pkg-config, which was supposed to solve much of this problem is
> incomplete, at least on GNU distributions, falls short.

There is not a 'single solution' that will fit the vast range of users
of PHP but current targeting seems to be aimed at a subset of both
coding style and practice at the expense of perfectly safe and
functional existing code.

>> Much the same with finding the source of problems in the mess
>> that composer has created!
>>
> [citation required]

I need to find the write-up on that. It was a well laid out blog on why
pdt/eclipse had problems with the composer approach to managing legacy code.

-- 
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