On 28/01/2014 19:50, Lester Caine wrote:
The best comment from that is
The solution is clear: build a full compatibility layer, not a conversion tool, into 3.x that makes 2.x code run without change and ABRUPTLY stop development on 2.x.
The only problem is should it run PHP5.2 code, or only PHP5.6? Little things like only supporting e_strict?
No, the biggest problem (apart from implementing and maintaining it!) is how to scope this compatibility layer.
If you have to turn it on with an ini setting - which generally means for the whole deployment, or at least the whole application - then you still have to have an almighty push to upgrade your application before turning it off.
What might be more interesting is if it could be limited by namespace, or by file, or something like that. Then you could include an entire PHP5 library in a project which was otherwise taking advantage of PHP5++ features, right down to invoking a different parser if necessary.
I was pondering a similar idea for existing notices - particularly E_STRICT, E_DEPRECATED, and E_NOTICE. The code base I work with relies on some really old PEAR modules, which we're planning to phase out in favour of something else. If we turn up error_reporting, we get a whole load of notices from code we're never going to maintain, drowning out any useful hints in code that was written last week.
Of course, to truly solve the adoption problem, the compatibility would have to be 100%...
--
Rowan Collins
[IMSoP]