Lester Caine wrote on 09/11/2014 22:39:
On 09/11/14 21:59, Rowan Collins wrote:
None of which has anything to do with E_STRICT. Strict notices aren't
indications that behaviour has changed; since we have E_DEPRECATED, they
shouldn't even indicate behaviour is about to change; they just indicate
that there might be a better way of doing what you're doing. I don't
know why you consider them to be in the same category as code
compatibility at all.
That the traditional method of using PHP5 is no longer politically
correct is the problem here. One can not use both methods of working at
the same time, and since in many cases the third party libraries HAVE
been upgraded and require a later version of PHP even to run, HELPING
users who had perfectly functional sites based on code that was created
using what are still current tutorials but which no longer produce
acceptable code is the main problem here. To pretend that PHP5.4 and
later can safely run legacy code is the problem, and these are BC breaks
that people are pretending have not happened simply because they assume
they can be ignored.
Yes, many pieces of software have a minimum PHP version to run, often
because they make use of useful new features, e.g. namespaces and
closures from PHP 5.3.
This is a very different kind of compatibility from old software not
working on newer versions of PHP; it is up to the projects in question
to decide which versions to support.
One method of working may be to configure a PHP setup which blocks any
use of e_strict compliant rules and make sure only legacy compatible
code is running. Then legacy sites can be kept running without the
effort of converting the code to clean e_strict compliance. The main
question that should probably be asked is if PHP7 will maintain this
source of confusion or ONLY allow e_strict compliance? Certainly I'd
prefer to see this on plugged. It is all to easy to have some upgrade
override your settings and introduce random breaks in things. THAT is
still a major source of agro, with third party libraries overriding
settings after one has ensured there were set correctly. It's not SIMPLY
ensuring that the hosting is set up correctly, it's the fact that any
library can screw that up!
There should be no problem with fixing some strict notices and not
others, so I don't understand your comment on blocking e_strict
compliance in order to run legacy code. Can you give an example of a
notice where you would want to actually *prevent compliance*, rather
than just ignoring the notice if you don't have time to fix it?
Again, updating code may well raise the minimum required PHP version,
but this is much more likely to be because the developer wants to take
advantage of new features, not because they're trying to run with no
strict notices.
--
*Rowan Collins*
*Senior Developer | CWT Digital*
*t.* 0845 456 0070 *w.*cwtdigital.com <http://www.cwtdigital.com/>
