At 20:48 12/08/2005, Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with Unicode_semantics=On I am wondering if it may not be time to break some more stuff and do a bit of spring cleaning. It would mean many apps would need some work to work on PHP 6, but at the same time I think it is work people would welcome since it would mostly involve removing hacks instead of adding them. And yes, I know this is pretty controversial, so take a few deep breaths before replying, please.
First of all, in general - I don't subscribe to the school of 'we broke something, why not break more'. With every feature we break, we reduce the chances of people upgrading, of legacy apps working, and we reduce the overall success chances of the new version. Compatibility breakup is not binary, it accumulates. The more features are broken, the worse the situation becomes.
1. Remove register_globals completely 2. Remove magic_quotes_*
Given what I said above, I don't see any motivation to remove register_globals or magic_quotes. I don't see how it buys us anything other than pissed off users and hordes of (sometimes exploitable) bugs that will result from sloppy audits. These changes alone would mean that a great deal of the applications would have to be 100% audited before an upgrade. Between us, developers welcoming forced labor due to upgrades is wishful thinking. People never like to be forced to go over their or other people's code regardless of the circumstances.
If we are to do anything about register_globals, perhaps we can change the name of the directive to something else (e.g. unprotected_globals), and of course keep its default 0. Admins will have to make an informed decision to turn it on again, and we can speak against it as strongly as we want in an upgrade guide.
Change the default of magic_quotes_gpc to 0 as well.
3. Add input filter extension which will include a mechanism for application developers to very easily turn it off which would swap the raw GPC arrays back in case the site had it turned on by default.
Sounds good.
4. Include an opcode cache by default. A lot of work has gone into pecl/apc recently, but I am not hung up on which one goes in.
Need to think about that one.
5. Remove safe_mode and focus on open_basedir
Sounds good.
6. Remove some stuff that has been marked deprecated since PHP 3/4 A couple of others that we could consider, but I don't actually think wins us much apart from academic purity (which I have never been all that keen on) are: 7. Make identifiers case-sensitive 8. Remove various function aliases
As I'm sure you'd agree, academic purity is not exactly why PHP won the hearts of the masses. I would almost argue the opposite. Features which only bother us due to academic purity are clearly ones we shouldn't touch. Even more so than register_globals and magic_quotes - which are not only impure but also problematic - there's no point forcing people to modify their code just because we feel like making PHP more academically pure. Other than creating a huge worldwide mess and slowing down migration, we're not going to gain anything (assuming we don't get any points for academic purity; PHP scored 100 when handed in as an academic project, by the way :).
Even if we forget about the users, and only think about ourselves - unless something drastic happens, we're going to look at supporting 4 major different versions simultaneously - 4.3/4.4, 5.0, 5.1 and 6.0. Is it really such a great idea to start breaking compatibility beyond what we absolutely have to?
I think you have some good ideas in that list, and some less good ideas. I'm worried about the wholesale mode that internals@ switched into, the almost unanimous "YES!" response, and the overall feeling that suddenly with 6.0 breakage comes without a price. That goes counter to our key design goals in the Unicode support, which were work-as-if-nothing-happened when unicode support is disabled.
Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
