Dragging the legacy users forward.

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

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]