On Feb 8, 2008 5:38 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote: > Frankly, I don't see why there is any vote whatsoever. It's plain > stupid to consider removing them when a fully backwards-compatible > solution exists that has no performance penalty, no security penalty, > and in fact no penalty at all.
It is not plain stupid to remove something when the underlying features do not exist. It is expected. Talking about BC in this case is a closed to be a complete non sense. For two reasons: 1. If can't do that between two major versions, let define a rule: we can't change _anything_ in PHP, no matter when (think: roll back all these fatal errors) 2. it is fixable in three lines (with braces). PEAR had much harder issues already, you can document the upgrade process (upgrade pear then php, make install will work if you include a full upgrading solution in go-pear.phar, if it is not the case already) Finally, I proposed a vote because we did vote about the _complete_ removal of these features a while back. Back to this time, it was not decided to keep them but to actually completely remove them. I thought (and still think) that it was necessary (and it was necessary) to bring this topic back to the list and to finally have a choice. That's why this list exists and not whatever IRC channel somewhere on EFNet :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
