Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82135
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain b1-systems.de designates 84.200.69.220 as permitted sender)
Message-ID: <54D74BFF.3070604@b1-systems.de>
Date: Sun, 08 Feb 2015 12:43:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <54D606D2.7030102@lsces.co.uk>
In-Reply-To: <54D606D2.7030102@lsces.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="JldfpARTN1jQONLomAPk9UTFirLCvtPck"
Subject: Re: [PHP-DEV] Dragging the legacy users forward.
From: lang@b1-systems.de (Ralf Lang)

--JldfpARTN1jQONLomAPk9UTFirLCvtPck
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Lester,

On 07.02.2015 13:36, Lester Caine wrote:
> My personal experience of PHP4 is simply one of having been developing
> all my code in PHP5.0 to 5.2 but ensuring that the code also still run
> clean on the PHP4 host.=20

Actually, PHP 4 changed a lot of things from PHP3. PHP 5.0.0 on the
other hand allowed you to run much legacy code while providing new and
better solutions to many problems. PHP 5 lasted about 10 years and the
later half of its life cycle actually amounted to pulling in new
features which should have gone into some PHP 6 while keeping an aging
core afloat on new hardware, new platforms. 32-bit is essentially dead,
Itanium is long forgotten for most applications, Arm and x86_64 are
standard.

In a perfect world, php 5 wouldn't have lasted that long and a lot of
userland code would have broken years ago, requiring trivial changes.

It was not until 5.3 that it was necessary to
> freeze the code base for 5.2 for every PHP4 host and maintain that fork=

> while 'taking advantage' of the new features of PHP5 that were not
> supported by PHP4. That is the code base that is currently populating
> the vast majority of PHP powered sites still, so while PHP4 is dead it'=
s
> footprint still lives on.

A lot of sites sticked with PHP5.3 because they were driven by
enterprise platforms which by definition won't upgrade during the life
cycle. That had its own costs and aches which are entirely not PHP's faul=
t.

> PHP7 is proposing a LOT of shiny new features which will break much
> legacy code.=20

Which features hurt you? Which features break code which would have been
best practice by php 5.0.0?

> But do we have to start taking greater care of third party
> libraries which as with the 5.2 to 5.4 switch means that two versions
> are needed? I've currently deliberately configured my development syste=
m
> so that PHP5 and PHP7 are running the same code set and once I have all=

> the missing extensions I can start playing further, but I need to work
> out how to allow 'needs PHP7' libraries in parallel.

Are you talking about userland code or extensions here?
Which php5 "best practice" feature would be broken by php 7?



--=20
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstra=C3=9Fe 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


--JldfpARTN1jQONLomAPk9UTFirLCvtPck
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTXTAIACgkQCs1dsHJ/X7D4rwCgnZ4NZI/8tfCvvXotgC4tHHWo
F4kAnjwyzlsub+DIAJxYnZV8KC8QUf+C
=luvQ
-----END PGP SIGNATURE-----

--JldfpARTN1jQONLomAPk9UTFirLCvtPck--