Guillaume Rossolini wrote:
To go back to Lester's original question, I decided to forgo PHP4 completely a few years ago, and fully take the PHP5 route. I do not use any framework or library that advertises it still works on PHP4.
Thanks for the comments Guillaume ... it's nice to here that I am not totally out on my own ;)
Personally as I have said before I came in just prior to PHP5 and so all my production work has always been on PHP5, but at that time I was porting tikiwiki to support Firebird, and then forking from that simply because their methods did not allow for a modular approach. That HAD to support the existing user base and PHP4 and it was some time before PHP5 only builds were adopted - actually on PHP5.2 :) Maintaining an open access to any database was just a natural requirement that I think 'tiki' itself has now lost but which we try to maintain. I simply can't understand how people cope with MySQL without an online backup system but that is another debate.
I was hoping that I could make PHP5.4/e_strict another fixed point, but I've already hit a problem that can't simply be worked around, so when running the e-commerce package e_strict and e_notice have to be switched off :( Reworking the entire translation system so that it does not redefine defines is just too much work at the moment, and other areas need major work to prevent other messages. The shops work and have a LOT of content, so reworking will be necessary, but it does not produce any financial advantage to do it at the moment! I'd avoided touching them up until now as they ARE working reliably. The plan WAS to make the next major release PHP5.4/e_strict compliant, but that's not going to happen now. We will just have to define a php.ini configuration that is required for both PHP5.3 and PHP5.4 to make things work.
Robert ... The main problem with the PHP5.3/4 changes are that the attitude with PHP5.3 was 'you don't have to worry', but very quickly that became 'now you do' simply by the switch of the default on e_strict. Perhaps when every existing project is totally e_strict complaint things can be different, but the amount of work needed to be carried out is simply not being achieved, so we have to decide if we want to spend time fixing things like PEAR - my own patches for which I've recently published - or simply switch off the problem and disable e_strict? I know I've been banging on about this for a long time - but I'm still trying to update my own and other peoples code to work cleanly today :( It would be nice to see a few more people helping ... rather than simply complaining at my moaning ... PHP created the problems 'full stop'
-- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
