Hey Everyone
I've put together a simple RFC[1] that lists features thats been
deprecated in 5.3, someone of them which I propose we remove in the
next version of PHP, depending on the version number. Most of the
features, which is listed below are taken from the old 6.0 NEWS[2]
file, and items from the old PHP6 TODO[3].
safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].
define_syslog_variables and its associated function
- Originally agreed to be removed in PHP6 during the 5.3 development,
if there is no objects then I will remove by the end of this weekend.
asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].
sql_safe_mode
- Theres currently an RFC in the works about this by Johannes[6].
session_register/session_is_registered/session_register
- Only needed for register_globals, Hannes removed those in PHP6.
enable_dl
- Is this really worth keeping, since
dl()was disabled on almost all
SAPIs except for CLI/CGI/Embed?
Support for Freetype 1 and GD 1
- Removed by Pierre in PHP6
Support for "continue" and "break" operators with non constant operands
- Removed by Dmitry in PHP6.
Undocumented and incomplete support for strings in list() operator
- Removed by Dmitry in PHP6 aswell.
detect_unicode/highlight_bg
- Two ini values thats been marked as removed features from PHP6 in
the manual. Not sure about detect_unicode, but highlight_bg is pretty
pointless.
y2k_compliance
- From the manual "Enforce year 2000 compliance (will cause problems
with non-compliant browsers)", we are in 2010, we should remove this
option and enable it by default and remove the checks. Perhaps Derick
got an insight here?
Class named constructors
- A feature thats been marked in the manual as something that would
be removed in a future version of PHP6. It was not to be knowing ever
decided to be kept or not, but now with the recent removal of them in
namespaces then I don't see a big point in keeping them.
If there is anything I forgot then let me know and I will add it to
the RFC, else discussions away!
[1] http://wiki.php.net/rfc/removal-of-deprecated-features
[2] http://svn.php.net/viewvc/php/php-src/branches/FIRST_UNICODE_IMPLEMENTATION/NEWS?view=markup
[3] http://wiki.php.net/todo/php60
[4] http://wiki.php.net/rfc/magicquotes
[5] http://marc.info/?l=php-internals&m=117640641605813&w=2
[6] http://wiki.php.net/rfc/drop_sql.safe_mode
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi!
asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].
IIRC last time we discussed it there was no solid reason found to do it
and some reasons not to. Could you remind why would it be useful to do it?
Class named constructors
- A feature thats been marked in the manual as something that would
be removed in a future version of PHP6. It was not to be knowing ever
decided to be kept or not, but now with the recent removal of them in
namespaces then I don't see a big point in keeping them.
I don't feel good with removing these for non-NS classes... BC break
would be big, though it would be relatively easy to write a script to
fix that.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
2010/4/9 Stanislav Malyshev stas@zend.com:
Hi!
asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].IIRC last time we discussed it there was no solid reason found to do it and
some reasons not to. Could you remind why would it be useful to do it?
I spend sometime reading archives and I should problably have written
in the initial post; Im just wondering about how many that actually
use it, and activate it since its disabled by default. So I guess the
question should have been about its usage statistics, since overall it
doesn't really cover anything that short_open_tags except the PI
collision.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].
+1
asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].
-1. Widely used, not a drain on the language. Better in some cases than
regular PHP tags.
sql_safe_mode
- Theres currently an RFC in the works about this by Johannes[6].
+1
Brian.
Kalle Sommer Nielsen wrote:
enable_dl
- Is this really worth keeping, since
dl()was disabled on almost all
SAPIs except for CLI/CGI/Embed?
Although it is not the most widespread use of PHP, people using things like
PHP-GTK probably take advantage of it.
Hi,
session_register/session_is_registered/session_register
- Only needed for register_globals, Hannes removed those in PHP6.
regiter_globals should be removed. It still exits, removing these is the
logical consequence after removing r_g.
enable_dl
- Is this really worth keeping, since
dl()was disabled on almost all
SAPIs except for CLI/CGI/Embed?
It's a good thing to be able to disable dl() with (Fast)CGI. For CLI
this setting shouldn't really matter, as long as dl() exists there.
y2k_compliance
- From the manual "Enforce year 2000 compliance (will cause problems
with non-compliant browsers)", we are in 2010, we should remove this
option and enable it by default and remove the checks. Perhaps Derick
got an insight here?
This is related to setcookie, not the date stuff and can be safely
removed.
Class named constructors
- A feature thats been marked in the manual as something that would
be removed in a future version of PHP6. It was not to be knowing ever
decided to be kept or not, but now with the recent removal of them in
namespaces then I don't see a big point in keeping them.
I personally would remove them, but I read the discussion about
namespaced classes and ctor names in a way hat there was no conesus for
removing it.
johannes
Hi,
Respectfully, FWIW...
safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_ca
ll_time_pass_reference
+1
asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].
-1
No way. While I abhor there use, many people do not.
sql_safe_mode
- Theres currently an RFC in the works about this by Johannes[6].
+1
session_register/session_is_registered/session_register
- Only needed for register_globals, Hannes removed those in PHP6.
+1
enable_dl
- Is this really worth keeping, since
dl()was disabled on almost all
SAPIs except for CLI/CGI/Embed?
+1
Support for Freetype 1 and GD 1
- Removed by Pierre in PHP6
+1
(With my sincere gratitude to Thomas for his work all those years)
Class named constructors
-1
Not in 5.x - the BC break here is huge.
Best Regards
Mike Robinson
If there is anything I forgot then let me know and I will add it to
the RFC, else discussions away!
There are a couple more that were documented as being removed from PHP 6:
- pdo_odbc.db2_instance_name
- session.bug_compat_42
Should these be added to this list? And I suppose session.bug_compat_warn goes along with session.bug_compat_42.
Regards,
Philip
2010/4/10 Philip Olson philip@roshambo.org:
If there is anything I forgot then let me know and I will add it to
the RFC, else discussions away!There are a couple more that were documented as being removed from PHP 6:
- pdo_odbc.db2_instance_name
- session.bug_compat_42
Should these be added to this list? And I suppose session.bug_compat_warn goes along with session.bug_compat_42.
Feel free to add them if they were listed as things that was supposed
to be removed in PHP6 on.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2010/4/9 Kalle Sommer Nielsen kalle@php.net:
safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].
I've updated the RFC with a patch for removing register_long_arrays if
there is any objections agains this.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2010/4/9 Kalle Sommer Nielsen kalle@php.net:
Hey Everyone
I've put together a simple RFC[1] that lists features thats been
deprecated in 5.3, someone of them which I propose we remove in the
next version of PHP, depending on the version number. Most of the
features, which is listed below are taken from the old 6.0 NEWS[2]
file, and items from the old PHP6 TODO[3].safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].define_syslog_variables and its associated function
- Originally agreed to be removed in PHP6 during the 5.3 development,
if there is no objects then I will remove by the end of this weekend.asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].sql_safe_mode
- Theres currently an RFC in the works about this by Johannes[6].session_register/session_is_registered/session_register
- Only needed for register_globals, Hannes removed those in PHP6.enable_dl
- Is this really worth keeping, sincedl()was disabled on almost all
SAPIs except for CLI/CGI/Embed?Support for Freetype 1 and GD 1
- Removed by Pierre in PHP6Support for "continue" and "break" operators with non constant operands
- Removed by Dmitry in PHP6.Undocumented and incomplete support for strings in list() operator
- Removed by Dmitry in PHP6 aswell.detect_unicode/highlight_bg
- Two ini values thats been marked as removed features from PHP6 in
the manual. Not sure about detect_unicode, but highlight_bg is pretty
pointless.y2k_compliance
- From the manual "Enforce year 2000 compliance (will cause problems
with non-compliant browsers)", we are in 2010, we should remove this
option and enable it by default and remove the checks. Perhaps Derick
got an insight here?Class named constructors
- A feature thats been marked in the manual as something that would
be removed in a future version of PHP6. It was not to be knowing ever
decided to be kept or not, but now with the recent removal of them in
namespaces then I don't see a big point in keeping them.If there is anything I forgot then let me know and I will add it to
the RFC, else discussions away![1] http://wiki.php.net/rfc/removal-of-deprecated-features
[2] http://svn.php.net/viewvc/php/php-src/branches/FIRST_UNICODE_IMPLEMENTATION/NEWS?view=markup
[3] http://wiki.php.net/todo/php60
[4] http://wiki.php.net/rfc/magicquotes
[5] http://marc.info/?l=php-internals&m=117640641605813&w=2
[6] http://wiki.php.net/rfc/drop_sql.safe_mode--
regards,Kalle Sommer Nielsen
kalle@php.net--
Hi!
I think we should also keep an eye on removing dead code.
Removing the useless: main/mergesort.c for example (Patch in attachment).
I think I don't have enough karma to commit this.
Regards,
--
Patrick Allaert
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
Hi Patrick
2010/4/15 Patrick ALLAERT patrickallaert@php.net:
Hi!
I think we should also keep an eye on removing dead code.
Removing the useless: main/mergesort.c for example (Patch in attachment).
I agree we should remove dead code, like Johannes commit to remove
php3_compat.h. As for the mergesort patch, is it used anywhere in PECL
or something? If not then I think we should remove it.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2010/4/15 Kalle Sommer Nielsen kalle@php.net:
Hi Patrick
2010/4/15 Patrick ALLAERT patrickallaert@php.net:
Hi!
I think we should also keep an eye on removing dead code.
Removing the useless: main/mergesort.c for example (Patch in attachment).I agree we should remove dead code, like Johannes commit to remove
php3_compat.h. As for the mergesort patch, is it used anywhere in PECL
or something? If not then I think we should remove it.
It's not, checked with http://php-og.mgdm.net/ and grep.
Patrick
safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].
+0
session_register/session_is_registered/session_register
- Only needed for register_globals, Hannes removed those in PHP6.
+1
enable_dl
- Is this really worth keeping, since
dl()was disabled on almost all
SAPIs except for CLI/CGI/Embed?
-1
Support for "continue" and "break" operators with non constant operands
- Removed by Dmitry in PHP6.
-1 — unless there is a very good reason for removing them.
y2k_compliance
- From the manual "Enforce year 2000 compliance (will cause problems
with non-compliant browsers)", we are in 2010, we should remove this
option and enable it by default and remove the checks. Perhaps Derick
got an insight here?
+1 — It's a switch, much like "make_it_faster". Can be safely removed.
Class named constructors
- A feature thats been marked in the manual as something that would
be removed in a future version of PHP6. It was not to be knowing ever
decided to be kept or not, but now with the recent removal of them in
namespaces then I don't see a big point in keeping them.
-1
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Hi,
on my previous mail I missed one thing:
magic_quotes_*
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].
Removing magic_quotes would be soooooooooooo great. BUT the issue is
that most users don't know about it. Many applications are more or less
secure due to its existence. The apps aren't fully secure but a few less
vectors.
I'm - for a while - thinking whether there is a way to notify
application developers about applications which run with m_q=On but no
check for it. As unless they are aware of it this will break many things
where people don't read the upgrading guides.
With the old PHP 6 I hoped the break was big enough. Now I'm not sure.
johannes
You must have been flying somethere in the Andromeda galaxy all this time!
magic_quotes, safe_mode and other stuff was announced depricated now for a
few years, there is big buzz going on about it and these features are
allready marked as depricated and throw warnings as of 5.3, some even as off
5.2. It's hard to miss articles, announce, conferences and numerous blog
entries literally from any PHP developer who has a blog that these features
are to be droped.
Please rewind from the past to the present day! :)
People, just drop all this stuff once and for all and forget it.
2010/4/16 Johannes Schlüter johannes@php.net
Hi,
on my previous mail I missed one thing:
magic_quotes_*
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].Removing magic_quotes would be soooooooooooo great. BUT the issue is
that most users don't know about it. Many applications are more or less
secure due to its existence. The apps aren't fully secure but a few less
vectors.I'm - for a while - thinking whether there is a way to notify
application developers about applications which run with m_q=On but no
check for it. As unless they are aware of it this will break many things
where people don't read the upgrading guides.With the old PHP 6 I hoped the break was big enough. Now I'm not sure.
johannes
You must have been flying somethere in the Andromeda galaxy all this time!
magic_quotes, safe_mode and other stuff was announced depricated now for a
few years, there is big buzz going on about it and these features are
allready marked as depricated and throw warnings as of 5.3, some even as off
5.2. It's hard to miss articles, announce, conferences and numerous blog
entries literally from any PHP developer who has a blog that these features
are to be droped.
Go to a random hosting site and look at there configuration - magic
quotes will be enabled. Look at some (not all) distributor packages -
magic quotes will be on. Many of them won't see it as it's "hidden" in
an error log which barely anybody read. Yes you do. You also read this
list. But that's a minority of our users. Most don't follow the
development closely. Most don't read blogs. Most don't know about
php.ini. Most don't know about security.
The people we interact with are just the tip of the iceberg. Most PHP
users are hidden on the internet.
I would love to get rid of this "feature" but I fear that many users
won't notice and i don't know how to tell them.
johannes
2010/4/16 Johannes Schlüter johannes@php.net
You must have been flying somethere in the Andromeda galaxy all this
time!magic_quotes, safe_mode and other stuff was announced depricated now for
a
few years, there is big buzz going on about it and these features are
allready marked as depricated and throw warnings as of 5.3, some even as
off
5.2. It's hard to miss articles, announce, conferences and numerous blog
entries literally from any PHP developer who has a blog that these
features
are to be droped.Go to a random hosting site and look at there configuration - magic
quotes will be enabled. Look at some (not all) distributor packages -
magic quotes will be on. Many of them won't see it as it's "hidden" in
an error log which barely anybody read. Yes you do. You also read this
list. But that's a minority of our users. Most don't follow the
development closely. Most don't read blogs. Most don't know about
php.ini. Most don't know about security.The people we interact with are just the tip of the iceberg. Most PHP
users are hidden on the internet.I would love to get rid of this "feature" but I fear that many users
won't notice and i don't know how to tell them.johannes
I think that the hosting providers will do notice, and either not migrate,
or send a mail to their users, warning to check their settings because if
they are depending on the magic quotes, they will be in danger.
So I think we don't have to wait for the shared hosting providers, because
they will catch up as slow or fast as we go.
Plus we don't know what will be the next version, so go ahead, commit into
the trunk, and when the release is coming, it will be decided whether or not
include this into it.
Tyrael
On Friday 16 April 2010 05:23:42 am Ferenc Kovacs wrote:
I think that the hosting providers will do notice, and either not migrate,
or send a mail to their users, warning to check their settings because if
they are depending on the magic quotes, they will be in danger.So I think we don't have to wait for the shared hosting providers, because
they will catch up as slow or fast as we go.
Given how long it took them to catch up to PHP 5 in the first place I don't
think we can count on that.
Such breakage should come in large chunks so that hosts only have to wring
their hands once every so often. Otherwise they just won't upgrade ever.
Most run on very thin margins.
--Larry Garfield
On Fri, Apr 16, 2010 at 10:38 PM, Larry Garfield larry@garfieldtech.comwrote:
On Friday 16 April 2010 05:23:42 am Ferenc Kovacs wrote:
I think that the hosting providers will do notice, and either not
migrate,
or send a mail to their users, warning to check their settings because if
they are depending on the magic quotes, they will be in danger.So I think we don't have to wait for the shared hosting providers,
because
they will catch up as slow or fast as we go.Given how long it took them to catch up to PHP 5 in the first place I don't
think we can count on that.Because PHP4 was supported for a long time. This is what I'm saying. If you
support 5,3 at least with security updates for years, they won't upgrade
because they don't have to.
Such breakage should come in large chunks so that hosts only have to wring
their hands once every so often. Otherwise they just won't upgrade ever.
Most run on very thin margins.
I disagree, from the point of the coder who has to port the application from
one version to other, it's easier, if there is only a few changes, which has
to be taken care of.
From the point of shared hosting providers, they don't want to change
anything from the BC perspective, so if you turn off some default value, or
throw deprecate warning, they will turn it back on, and ignore the errors.
When this is not possible (because you removed some feature), they won't
upgrade, as long as there is security support for the old version.
Tyrael
On Fri, Apr 16, 2010 at 10:38 PM, Larry Garfieldlarry@garfieldtech.comwrote:
On Friday 16 April 2010 05:23:42 am Ferenc Kovacs wrote:
I think that the hosting providers will do notice, and either not
migrate,
or send a mail to their users, warning to check their settings because if
they are depending on the magic quotes, they will be in danger.So I think we don't have to wait for the shared hosting providers,
because
they will catch up as slow or fast as we go.Given how long it took them to catch up to PHP 5 in the first place I don't
think we can count on that.Because PHP4 was supported for a long time. This is what I'm saying. If you
support 5,3 at least with security updates for years, they won't upgrade
because they don't have to.Such breakage should come in large chunks so that hosts only have to wring
their hands once every so often. Otherwise they just won't upgrade ever.
Most run on very thin margins.I disagree, from the point of the coder who has to port the application from
one version to other, it's easier, if there is only a few changes, which has
to be taken care of.
From the point of shared hosting providers, they don't want to change
anything from the BC perspective, so if you turn off some default value, or
throw deprecate warning, they will turn it back on, and ignore the errors.
When this is not possible (because you removed some feature), they won't
upgrade, as long as there is security support for the old version.Tyrael
Just some anecdotal evidence regarding this issue:
http://it.slashdot.org/story/10/04/16/1646244/ClamAV-Forced-Upgrade-Breaks-Email-Servers
http://it.slashdot.org/story/10/04/16/1646244/ClamAV-Forced-Upgrade-Breaks-Email-Servers
The 2 year old version of the ClamAV daemon (0.94) is incompatible with
the new signature updates (for the also free 0.95 and 0.96 versions), so
the old version crashed.
The funny part is ClamAV was announcing this for at least 6 months. On
mailing lists, their homepage, plus the daemon was flooding the server
log every day with warnings.
Still, some admins did not care about a product that couldn't be more
explicitly a factor of their network security. Therefore, in my opinion,
waiting for admins to upgrade is futile, useless, and just keeps users
in security-fairyland for more time.
Pas
You must have been flying somethere in the Andromeda galaxy all this time!
magic_quotes, safe_mode and other stuff was announced depricated now for a
few years, there is big buzz going on about it and these features are
allready marked as depricated and throw warnings as of 5.3, some even as off
5.2. It's hard to miss articles, announce, conferences and numerous blog
entries literally from any PHP developer who has a blog that these features
are to be droped.Go to a random hosting site and look at there configuration - magic
quotes will be enabled. Look at some (not all) distributor packages -
magic quotes will be on. Many of them won't see it as it's "hidden" in
an error log which barely anybody read. Yes you do. You also read this
list. But that's a minority of our users. Most don't follow the
development closely. Most don't read blogs. Most don't know about
php.ini. Most don't know about security.The people we interact with are just the tip of the iceberg. Most PHP
users are hidden on the internet.I would love to get rid of this "feature" but I fear that many users
won't notice and i don't know how to tell them.
And a related issue is that magical quotes are still enabled by default in PHP, and removing a security feature that was enabled by default is not a simple matter. Not sure if disabling it by default (in trunk) is a preferred intermediate step, but it's possible.
Regards,
Philip
+1 to remove magic_quotes from trunk
Most of us want to get rid of this feature. I agree with you that some
people probably don't know php.ini and magic_quotes but i'm not sure
that even if we wait we'll find a better way to tell them about those.
People (not all) on shared hosting don't really pay attention to PHP
upgrades on their server even if it's a major release and it's sadly
not going to change.
Pierrick
2010/4/16 Johannes Schlüter johannes@php.net:
You must have been flying somethere in the Andromeda galaxy all this time!
magic_quotes, safe_mode and other stuff was announced depricated now for a
few years, there is big buzz going on about it and these features are
allready marked as depricated and throw warnings as of 5.3, some even as off
5.2. It's hard to miss articles, announce, conferences and numerous blog
entries literally from any PHP developer who has a blog that these features
are to be droped.Go to a random hosting site and look at there configuration - magic
quotes will be enabled. Look at some (not all) distributor packages -
magic quotes will be on. Many of them won't see it as it's "hidden" in
an error log which barely anybody read. Yes you do. You also read this
list. But that's a minority of our users. Most don't follow the
development closely. Most don't read blogs. Most don't know about
php.ini. Most don't know about security.The people we interact with are just the tip of the iceberg. Most PHP
users are hidden on the internet.I would love to get rid of this "feature" but I fear that many users
won't notice and i don't know how to tell them.johannes
Removing magic_quotes would be soooooooooooo great. BUT the issue is
that most users don't know about it. Many applications are more or less
secure due to its existence. The apps aren't fully secure but a few less
vectors.
One way to remove magic_quotes without opening massive quantities of
security holes would be implementing taint mode support
(http://wiki.php.net/rfc/taint) and having the default taint_error_level
be E_FATAL.
Yes, this creates a painful upgrade path for the multitudes using
insecure coding practices. But it will hurt a lot less than having their
applications inadvertently subverted by hackers/crackers/spammers/etc due
to upgrading PHP.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
I've added the patch to remove magic quotes from trunk on the RFC.
Is there any comments/objection against this patch ?
Pierrick
2010/4/8 Kalle Sommer Nielsen kalle@php.net:
Hey Everyone
I've put together a simple RFC[1] that lists features thats been
deprecated in 5.3, someone of them which I propose we remove in the
next version of PHP, depending on the version number. Most of the
features, which is listed below are taken from the old 6.0 NEWS[2]
file, and items from the old PHP6 TODO[3].safe_mode/register_globals/register_long_arrays/magic_quotes_*/allow_call_time_pass_reference
- Something we have long time been wanted to remove from PHP, I don't
see a big reason to keep those in the next version, even if its going
to be a 5.4, since we already removed things like
zend.ze1_compatibility_mode. See the magic quotes RFC[4].define_syslog_variables and its associated function
- Originally agreed to be removed in PHP6 during the 5.3 development,
if there is no objects then I will remove by the end of this weekend.asp_tags
- Proposed to be removed aswell, Tony had a patch for this[5].sql_safe_mode
- Theres currently an RFC in the works about this by Johannes[6].session_register/session_is_registered/session_register
- Only needed for register_globals, Hannes removed those in PHP6.enable_dl
- Is this really worth keeping, sincedl()was disabled on almost all
SAPIs except for CLI/CGI/Embed?Support for Freetype 1 and GD 1
- Removed by Pierre in PHP6Support for "continue" and "break" operators with non constant operands
- Removed by Dmitry in PHP6.Undocumented and incomplete support for strings in list() operator
- Removed by Dmitry in PHP6 aswell.detect_unicode/highlight_bg
- Two ini values thats been marked as removed features from PHP6 in
the manual. Not sure about detect_unicode, but highlight_bg is pretty
pointless.y2k_compliance
- From the manual "Enforce year 2000 compliance (will cause problems
with non-compliant browsers)", we are in 2010, we should remove this
option and enable it by default and remove the checks. Perhaps Derick
got an insight here?Class named constructors
- A feature thats been marked in the manual as something that would
be removed in a future version of PHP6. It was not to be knowing ever
decided to be kept or not, but now with the recent removal of them in
namespaces then I don't see a big point in keeping them.If there is anything I forgot then let me know and I will add it to
the RFC, else discussions away![1] http://wiki.php.net/rfc/removal-of-deprecated-features
[2] http://svn.php.net/viewvc/php/php-src/branches/FIRST_UNICODE_IMPLEMENTATION/NEWS?view=markup
[3] http://wiki.php.net/todo/php60
[4] http://wiki.php.net/rfc/magicquotes
[5] http://marc.info/?l=php-internals&m=117640641605813&w=2
[6] http://wiki.php.net/rfc/drop_sql.safe_mode--
regards,Kalle Sommer Nielsen
kalle@php.net