Lukas Smith wrote:
to keep customers. This half-assed attempt at maintain BC is what is really causing major problems.
The problem would be that this new PHP would be a wild mix of all different changes. While I wouldn't mind a shiny new PHP with &-references removed altogether which always copies object handles (as Mike Ford calls them) and could live with public instead of var everywhere I wouldn't like being forced to e.g. use exceptions if the decision would be made to use them in the standard library. So the whole package could go down the drain because of one part of it (which might be a different part for individual developers). The BC approach works around this by allowing me to ignore new features I don't want. Two things to consider: 1) If the PHP maintainers are getting sick of BC then it might be better to break BC than to lose maintainers. 2) On the other hand one should not forget that the amount of PHP4 code around is much bigger than the size of the PHP source itself. So even if BC is abandoned you can't simply drop PHP4 altogether (as hinted at in this thread) without causing a lot of damage. One possibility I see would be to have PHP<x> (insert your favourite number here) drop compatibility with PHP4 and have some maintainers work on PHP4 bug fixes and some on PHP6 features/bugs. It's kinda unclear what would happen to PHP5 - PHP<x-1> though its maintainers would face the same BC+new-stuff situation we have right now which doesn't seem to be popular. Trying to help deciding which way to go, ignore me if you don't care ;-) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
