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. 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.
Moving code to a post PHP5.4 host is NOT simply a matter of configuring
the configuration to hid the problems. Many features relied on by code
up to 5.2 had been removed and so code HAS to be reworked ... or hosting
remains with some pre5.4 compromise which accounts for the current usage
of PHP5.3
PHP7 is proposing a LOT of shiny new features which will break much
legacy code. So the question has to be just what is the plan regarding
cross version support. I see that the general consensus is PHP5 should
just run? 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 system
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.
There IS a clear speed advantage, but I'm not sure yet if that is PHP5.4
to later 5.x or simply 5 to 7 improvements. I'm don't see any reason to
think it's not simply 5->7 so I can then check the impact of things like
'unconstrained integer', however THAT is going to require a lot more
care with the code than simply 'it runs' :( In the past using 32 bit
builds has been a fix for many problems, not just the windows platform
ones, so removing that prop requires a lot more care!
--
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
Hi Lester,
PHP7 is proposing a LOT of shiny new features which will break much
legacy code. So the question has to be just what is the plan regarding
cross version support. I see that the general consensus is PHP5 should
just run?
Do you mean release 5.7 or extend life of 5.6?
I'm +1 for both options.
Extending 5.6 life may achieved consensus.
Perhaps, 2 year security support?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Lester,
PHP7 is proposing a LOT of shiny new features which will break much legacy code. So the question has to be just what is the plan regarding cross version support. I see that the general consensus is PHP5 should just run?Do you mean release 5.7 or extend life of 5.6?
I'm +1 for both options.
Extending 5.6 life may achieved consensus.
Perhaps, 2 year security support?
Well I don't remember any such restriction on PHP4? Although there is
still a compatibility library to emulate some later features where PHP4
did not provide them. But we are only talking about 'PHP4' being stable
up to PHP5.2 and quoting periods here is irrelevant. Nobody is currently
taking any notice of the fact HP5.2 and 5.3 are no longer supported and
it's that the removal of features was badly managed that has created
this problem.
From a day to day survival point of view I have to decide what to do
with currently functional sites that ARE still on PHP5.2 hosting. The
bulk of the sites that have been moved to PHP5.4 still require regular
work because people keep finding fault with one mobile device or another
not displaying 'bootstrap3' properly which is another major upgrade path
that is the MAIN reason for reworking sites and the one that prevents
simple sticking plasters to hack PHP changes.
I spent most of yesterday trying to get a key component of a financial
site into a format that it could even be used on a mobile phone. And
failed, so now I have to find another way to meet the LEGAL requirement
that the customer has to comply with.
So in general no I'm not talking about having to fix PHP5 code to some
PHP7 compliant state, I AM talking about current PHP5 code simply
working as PHP4 did into PHP5 hosting! CURRENTLY my php7 test site is
running PHP5.4 live code so I don't think I'm out of line here, but if
something goes in which causes my php7 test site to crash then I would
prefer that to be sorted by PHP7 rather than having to upgrade to some
as yet unavailable PHP5.x, although I would be more than happy if I can
simply amend the live code and make both work.
--
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
"Lester Caine" wrote in message news:54D73248.9030509@lsces.co.uk...
Hi Lester,
PHP7 is proposing a LOT of shiny new features which will break much legacy code. So the question has to be just what is the planregarding
cross version support. I see that the general consensus is PHP5
should
just run?Do you mean release 5.7 or extend life of 5.6?
I'm +1 for both options.
Extending 5.6 life may achieved consensus.
Perhaps, 2 year security support?Well I don't remember any such restriction on PHP4? Although there is
still a compatibility library to emulate some later features where PHP4
did not provide them. But we are only talking about 'PHP4' being stable
up to PHP5.2 and quoting periods here is irrelevant. Nobody is currently
taking any notice of the fact HP5.2 and 5.3 are no longer supported and
it's that the removal of features was badly managed that has created
this problem.From a day to day survival point of view I have to decide what to do
with currently functional sites that ARE still on PHP5.2 hosting. The
bulk of the sites that have been moved to PHP5.4 still require regular
work because people keep finding fault with one mobile device or another
not displaying 'bootstrap3' properly which is another major upgrade path
that is the MAIN reason for reworking sites and the one that prevents
simple sticking plasters to hack PHP changes.I spent most of yesterday trying to get a key component of a financial
site into a format that it could even be used on a mobile phone. And
failed, so now I have to find another way to meet the LEGAL requirement
that the customer has to comply with.So in general no I'm not talking about having to fix PHP5 code to some
PHP7 compliant state, I AM talking about current PHP5 code simply
working as PHP4 did into PHP5 hosting! CURRENTLY my php7 test site is
running PHP5.4 live code so I don't think I'm out of line here, but if
something goes in which causes my php7 test site to crash then I would
prefer that to be sorted by PHP7 rather than having to upgrade to some
as yet unavailable PHP5.x, although I would be more than happy if I can
simply amend the live code and make both work.
Well said. If it is not possible to have a single codebase that runs in both
PHP 5 AND PHP 7 then that will be a total disaster.
--
Tony Marston
Well said. If it is not possible to have a single codebase that runs in
both PHP 5 AND PHP 7 then that will be a total disaster.
Of course you can have a single codebase running both on PHP5 and PHP7,
unless you want to use PHP7-only features.
But that doesn't mean that any codebase that currently runs on PHP5 will
keep working on PHP7 without any changes. Most of the "modern" codebases
probably will though.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Well said. If it is not possible to have a single codebase that runs in
both PHP 5 AND PHP 7 then that will be a total disaster.Of course you can have a single codebase running both on PHP5 and
PHP7, unless you want to use PHP7-only features.
It may be true right now, but it is not inevitable. There are certain
behaviour or syntax changes that could, theoretically, require the same
feature to be written differently in the two versions.
Luckily, such changes are rare, and are usually spotted and avoided (as
with the change to DateTime typehinting mentioned recently), but it's
not something that goes without saying.
Regards,
--
Rowan Collins
[IMSoP]
"Matteo Beccati" wrote in message news:54D74C68.6070402@beccati.com...
Well said. If it is not possible to have a single codebase that runs in
both PHP 5 AND PHP 7 then that will be a total disaster.Of course you can have a single codebase running both on PHP5 and PHP7,
unless you want to use PHP7-only features.But that doesn't mean that any codebase that currently runs on PHP5 will
keep working on PHP7 without any changes. Most of the "modern" codebases
probably will though.
But there is a vociferous group who want to change the language in a
revolutionary way instead of an evolutionary way. They want to drop weak
typing and replace it with strict typing, they want to replace a lot of
function names with something "more consistent", and they want PHP to have a
"purer" OO model so that instead of "string = strtoupper($string)" you must
use "$string->toUpper". These revolutionaries want PHP 7 to be a different
language, not an extension of the existing PHP 5 version.
--
Tony Marston
But there is a vociferous group who want to change the language in a
revolutionary way instead of an evolutionary way. They want to drop weak
typing and replace it with strict typing, they want to replace a lot of
function names with something "more consistent", and they want PHP to
have a "purer" OO model so that instead of "string =
strtoupper($string)" you must use "$string->toUpper". These
revolutionaries want PHP 7 to be a different language, not an extension
of the existing PHP 5 version.
I don't see any such RFC for PHP7. So it's probably worth if we avoid
complaining about something that's not being proposed and certainly not
going to happen.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
"Matteo Beccati" wrote in message news:54D883D2.5020009@beccati.com...
But there is a vociferous group who want to change the language in a
revolutionary way instead of an evolutionary way. They want to drop weak
typing and replace it with strict typing, they want to replace a lot of
function names with something "more consistent", and they want PHP to
have a "purer" OO model so that instead of "string =
strtoupper($string)" you must use "$string->toUpper". These
revolutionaries want PHP 7 to be a different language, not an extension
of the existing PHP 5 version.I don't see any such RFC for PHP7. So it's probably worth if we avoid
complaining about something that's not being proposed and certainly not
going to happen.
There may not be an actual RFC for any of these YET, but the
revolutionaries are still out there, plotting and scheming in their dark
corners. They will be the ones who leap on an innocent-sounding feature and
silently convert it to something more insidious. Just look at how "type
hinting" has been turned into "type enforcement" as an example.
--
Tony Marston
There may not be an actual RFC for any of these YET, but the
revolutionaries are still out there, plotting and scheming in their dark
corners. They will be the ones who leap on an innocent-sounding feature
and silently convert it to something more insidious. Just look at how
"type hinting" has been turned into "type enforcement" as an example.
Only if you're willing to use it. But with the current proposal, no 3rd
party library developer can actually force you to use strict typing if
you don't want to. What's insidious about it?
That's the reason I voted "yes", even though I dislike the idea of
strict scalar type hinting in PHP.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Tony Marston wrote on 09/02/2015 10:07:
There may not be an actual RFC for any of these YET, but the
revolutionaries are still out there, plotting and scheming in their
dark corners. They will be the ones who leap on an innocent-sounding
feature and silently convert it to something more insidious.
Seriously!? PHP's decision process is wide open to scrutiny, and
controversial features are nearly always loudly debated, to the point of
holding up progress at times. The idea that someone could somehow slip a
critically breaking change into the language insidiously is utterly
ridiculous, and an insult to all the people who work hard honestly
trying to make the language better for everyone.
Just look at how "type hinting" has been turned into "type
enforcement" as an example.
OK, I'll look; I'll look at how many hours of debating it's generated,
and how many different points of view have been put in, and how hard
Andrea has worked to make the current proposal a compromise which breaks
the deadlock. This is so completely the opposite of "revolutionaries
plotting in dark corners" that the comparison is laughable.
Keep your conspiracy theories for Youtube, and concern yourself with the
real proposals that are actually happening, all of which are evolutions
of the language.
Regards,
Rowan Collins
[IMSoP]
Hi Lester,
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.
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 fault.
PHP7 is proposing a LOT of shiny new features which will break much
legacy code.
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 system
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?
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
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 fault.PHP7 is proposing a LOT of shiny new features which will break much
legacy code.
Which features hurt you? Which features break code which would have been
best practice by php 5.0.0?
Currently it is impossible to run the PHP5.2 code base on PHP5.4. That
is a simple fact. So I can't do between 5.2 and 5.4 what I am currently
doing between 5.4 and 7. The code has to be reworked ... so what ever
anybody says PHP5 .4 IS PHP6 in terms of major breaks. 'Best Practice'
is at best dependent on just what style of working a particular faction
wants. Is 'strict typing' an example of future best practice? Is
e_strict compliant code best practice? It is that which I base the move
from 5.2 to 5.4 on. If I add a library using namespaces often things
fail to work so I stick with the 'non-namespace' version? Best practice
these days is I suppose to be using composer for everything? None of
this was around by 5.0.0 days yet the bulk of my framework code is well
over 10 years old and at one time one could select you preferred
database install and run. Nowadays just keeping a small subset of
database engines working is all we can manage.
PHP is no longer the simple user friendly base that it once was!
--
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
Currently it is impossible to run the PHP5.2 code base on PHP5.4. That
is a simple fact. So I can't do between 5.2 and 5.4 what I am currently
doing between 5.4 and 7. The code has to be reworked ... so what ever
anybody says PHP5 .4IS PHP6 in terms of major breaks.
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4, but
none for which the new solution didn't also work under 5.2 (or, at
least, for which a compromise didn't exist which worked under both).
Call-time pass-by-reference was all over the place, for instance, but
rarely actually needed, and if it was, replacing it with a
pass-by-reference declaration would leave you with something working
fine under 5.2.
It's frustrating not being able to use new features when you need to
support an outdated installation, and finding third-party libraries
which support old versions of PHP can be tricky. 5.3 was the big
breaking point there, because although we didn't refactor our code to
use namespaces, libraries quickly came to be written with them (which is
a good thing) so automatically have that as a minimum version requirement.
The biggest problem with keeping userland code cross-version compatible
is usually syntax - behaviours and standard functions can, if it's
really necessary, be worked around by checking PHP_VERSION, or "if ( !
function_exists('blah') { function blah { ... } }". But because there's
no equivalent of a C pre-processor, you can't work around syntax which
wasn't valid on older versions, other than by not using it (it would
have been lovely to include closures in code which was simply
unreachable on 5.2 hosts, but if 5.2 needed to parse that file, it was
impossible).
Clearly, your experience is different; perhaps some specific examples of
the problems which forced you to fork the codebase, rather than adapt it
into a cross-compatible state, would help people look out for the same
situation arising in future.
Regards,
--
Rowan Collins
[IMSoP]
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4, but
none for which the new solution didn't also work under 5.2 (or, at
least, for which a compromise didn't exist which worked under both).
Call-time pass-by-reference was all over the place, for instance, but
rarely actually needed, and if it was, replacing it with a
pass-by-reference declaration would leave you with something working
fine under 5.2.
Rewriting the the code to make it work is exactly what is taking the
time, but I DID also adopt the standard that e_strict would be required
and up until that time all the code I was involved with ran with
display_errors ON which was a conscious choice to pick up problems that
crept in when they happened rather than having to trawl through hundreds
of log files every few days. Remove 'register_globals' and a site breaks
until such time as the code is reworked, but that code also needs to be
brought up to a better standard rather than simply hacking the
register_globals and other removed or backwards incompatible problems.
Since a large part of the code I am now supporting I did not write,
simply trying to decipher some of the strange tricks coders used to get
up to is a nightmare, and some of the new 'styles' of writing things are
going to make things considerably worse for those who are going to have
to maintain this code in the future.
There are several pages of things that were good practice in PHP5.0 code
which will now give white screens if one tries to run them on a 'good
practice' PHP5.4 setup. Fortunately I think that I've already covered
most of the later problems in trying to make the legacy code clean
e_strict code so switching from 5.4 to 5.6 should not cause a problem,
but I'm not ready to move production beyond 5.4 as yet.
If I was only worried about a couple of sites then things would be
different, but the current catalogue is some 120 different sites some of
which are pigging ASP and I will be glad when I can finally pull them
over to PHP.
--
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
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4, but
none for which the new solution didn't also work under 5.2 (or, at
least, for which a compromise didn't exist which worked under both).
Call-time pass-by-reference was all over the place, for instance, but
rarely actually needed, and if it was, replacing it with a
pass-by-reference declaration would leave you with something working
fine under 5.2.
Rewriting the the code to make it work is exactly what is taking the
time, but I DID also adopt the standard that e_strict would be required
OK, so that's your choice - you have deliberately set yourself a higher
bar than PHP has, in order to end up with better code. Good for you.
I can also imagine that setting that high bar may make it harder to make
the kind of compromises that are inevitable when writing code intended
to run on multiple versions simultaneously.
Remove 'register_globals' and a site breaks
until such time as the code is reworked, but that code also needs to be
brought up to a better standard rather than simply hacking the
register_globals and other removed or backwards incompatible problems.
If all you're worried about is running on multiple versions of PHP, the
manual includes a one-liner to emulate register_globals. Again,
reworking it is a good idea, but not something that PHP actually forces
on you.
Some of the new 'styles' of writing things are
going to make things considerably worse for those who are going to have
to maintain this code in the future.
If you're writing code that you know will be hard to maintain in the
future, you're doing something wrong. If by slavishly following a style
guide you've ended up with a poor architecture, you need a better style
guide, or a better understanding of why those styles are preferred.
Alternatively, I may have misunderstood that sentence, in which case I
apologise in advance.
There are several pages of things that were good practice in PHP5.0 code
which will now give white screens if one tries to run them on a 'good
practice' PHP5.4 setup.
Maybe, but most of them can be replaced by code which runs fine on both
versions. It may not be the best code you could write if you knew you
could rely on new features, but it works.
For instance, when the preg_replace "/e" modifier is removed, it will
still be possible to write code that uses preg_replace_callback() with
the almost-as-ugly create_function() instead of a real anonymous
function. That gives you compatibility all the way back to 5.0, and all
the way forward to 7.0; it's also slightly less likely to be a security
hole, so you're improving your code base by doing it. If you decide that
good code is more important than cross-compatibility, you can go ahead
and use the 5.3+ closure syntax instead, but no decision made on this
list will have forced that on you.
Regards,
--
Rowan Collins
[IMSoP]
Some of the new 'styles' of writing things are
going to make things considerably worse for those who are going to have
to maintain this code in the future.If you're writing code that you know will be hard to maintain in the
future, you're doing something wrong. If by slavishly following a style
guide you've ended up with a poor architecture, you need a better style
guide, or a better understanding of why those styles are preferred.Alternatively, I may have misunderstood that sentence, in which case I
apologise in advance.
Something I have been asking for for the last few years IS a better
'style guide' ... There are a growing number of 'styles' and the current
debate is to allow even more! Just about every framework has a different
style of handling database abstraction, and that seems to change every
major version as well. All of my own code is based around ADOdb, but now
it seems THAT is not an acceptable style of code these days.
Anyway I now have PHP56.lsces.org.uk running with the latest PHP5. It's
throwing megabytes of data into the error log but there ACTUALLY seem to
be less in the php7 error log ... need to figure that out, but I've
currently hit the latest brick wall as mbstring is not compiling! Most
of the others have compiled fine, but currently there is a blank front
page until I can work out what is going wrong ... that and smarty is
throwing errors ...
--
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
Lester Caine wrote on 09/02/2015 01:31:
Some of the new 'styles' of writing things are
going to make things considerably worse for those who are going to have
to maintain this code in the future.If you're writing code that you know will be hard to maintain in the
future, you're doing something wrong. If by slavishly following a style
guide you've ended up with a poor architecture, you need a better style
guide, or a better understanding of why those styles are preferred.Alternatively, I may have misunderstood that sentence, in which case I
apologise in advance.
SomethingI have been asking for for the last few years IS a better
'style guide' ... There are a growing number of 'styles' and the current
debate is to allow even more! Just about every framework has a different
style of handling database abstraction, and that seems to change every
major version as well. All of my own code is based around ADOdb, but now
it seems THAT is not an acceptable style of code these days.
This is true of pretty much every language under the sun, and isn't
really relevant to the internals of the language. It's about finding
books, websites, libraries, and experts who you trust and agree with on
matters of opinion and prediction. PHP-FIG is working on standardising
some aspects, but others will always be a matter of fashion and taste.
Regards,
Rowan Collins
[IMSoP]