> I'm not sure what you're saying here exactly, but if you are suggesting > that PHP.future, whatever this future version number is - is going to be a > strictly typed language, with total disregard for BC /../
I'm suggesting that PHP could stop worrying about "super legacy code which uses short open tags and nobody wants to touch it" and move on. Code that nobody wants to touch can just use PHP LTS and PHP project could focus on programmers and actively developed projects. > Whether it's a fork or LTS - this is a *radical* duplication of effort. Bigger than creating P++ and having two different and competing languages? I highly doubt. Also, the LTS line could (and probably should) be sponsored. For example, most of BC breaks does not seem to be a problem for OSS. This is mostly a problem for companies with big and legacy applications, who don't want to spend money on upgrading them. If BC breaks are really such a big problem for thousands of companies, there should be no problem to find founders to pay ~1 developer for maintaining LTS line and backporting security fixes. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
