# PHP 6.0 Wishlist - Thread: https://externals.io/message/17883 - Original archive: https://news-web.php.net/php.internals/17883 - Started by Rasmus Lerdorf on 2005-08-12T17:48:20+00:00 - Messages: 203 - Page 1 of 9: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/17883.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #17883 — Rasmus Lerdorf — 2005-08-12T17:48:20+00:00 URL: https://externals.io/message/17883#17883 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. 1. Remove register_globals completely 2. Remove magic_quotes_* 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. 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. 5. Remove safe_mode and focus on open_basedir 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 -Rasmus --- ## #17885 — Derick Rethans — 2005-08-12T17:54:16+00:00 URL: https://externals.io/message/17883#17885 · In reply to: #17883 > 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. > > 1. Remove register_globals completely +1 > 2. Remove magic_quotes_* +1 > 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. +1 > 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. +1 > 5. Remove safe_mode and focus on open_basedir +1 (I'd say remove both though ;-) > 6. Remove some stuff that has been marked deprecated since PHP 3/4 +1 > 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 You mean: make *all* identifiers case-sensitive? (Currently varnames are already case-sensitive). If you meant all: +1 > 8. Remove various function aliases +1 Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #17886 — Andrei Zmievski — 2005-08-12T17:59:07+00:00 URL: https://externals.io/message/17883#17886 · In reply to: #17883 > 1. Remove register_globals completely Yes. > 2. Remove magic_quotes_* Yes. Nothing but trouble, this one. > 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. Yes. > 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. Emphatically yes. > 5. Remove safe_mode and focus on open_basedir Yes. > 6. Remove some stuff that has been marked deprecated since PHP 3/4 I don't have an exact list of this, but yes. > 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 I've already stuck my neck out on this one a couple of times, and haven't gotten much traction, but sure.. > 8. Remove various function aliases Could be nice to clean up. -Andrei --- ## #17887 — Ilia Alshanetsky — 2005-08-12T18:01:13+00:00 URL: https://externals.io/message/17883#17887 · In reply to: #17883 Rasmus Lerdorf wrote: > 1. Remove register_globals completely +1 > 2. Remove magic_quotes_* +1 > 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. +1 As long as swapping for raw takes no more then a function call per input type, ala restore_input(PHP_GET). > 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. +1 As long as it does not prevent alternate solutions from being used. > 5. Remove safe_mode and focus on open_basedir +1 > 6. Remove some stuff that has been marked deprecated since PHP 3/4 Let's do this on a case by case basis, perhaps make a list of all deprecated items and vote on them individually. > 8. Remove various function aliases That closely relates to 6, so same comments apply. Ilia --- ## #17888 — Gareth Ardron — 2005-08-12T18:02:48+00:00 URL: https://externals.io/message/17883#17888 · In reply to: #17883 Rasmus Lerdorf wrote: >1. Remove register_globals completely >2. Remove magic_quotes_* >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. > > Yes please :-) That'd remove half my admin headaches from shared boxes. >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. > > I'm not sure if it should be turned on by default - maybe ini settable. Personally, I've come up against a number of issues with apc & session support and wouldn't really trust developing in an environment with an opcode cache turned on. No real opinion on the rest though. Would make sense for any api changes for modules to be pushed through in the same release though as well, as we're going to have to change our modules for unicode support anyway. --- ## #17889 — Wez Furlong — 2005-08-12T18:04:03+00:00 URL: https://externals.io/message/17883#17889 · In reply to: #17883 I agree on all points. Case sensitivity would be nice IMO, but I can continue to live without it. --Wez. > 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. > > 1. Remove register_globals completely > > 2. Remove magic_quotes_* > > 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. > > 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. > > 5. Remove safe_mode and focus on open_basedir > > 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 > > -Rasmus --- ## #17890 — George Schlossnagle — 2005-08-12T18:05:51+00:00 URL: https://externals.io/message/17883#17890 · In reply to: #17883 > 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. > > 1. Remove register_globals completely +1 > 2. Remove magic_quotes_* +1 > 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. That seems a bit scary, and almost as if it would defeat the purpose. I'm all for an input filter extension, but it should be one that can't be easily neutered by (potentially malicious) applications. > 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. +1 > 6. Remove some stuff that has been marked deprecated since PHP 3/4 +1. I agree with Ilia that this should be done on a case-by-case basis. > 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 +1 9. Radically change all the operator syntaxes. Oh wait, that's Perl 6.0, sorry. George --- ## #17891 — Sterling Hughes — 2005-08-12T18:13:54+00:00 URL: https://externals.io/message/17883#17891 · In reply to: #17883 +1 to all things here. -Sterling > 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. > > 1. Remove register_globals completely > > 2. Remove magic_quotes_* > > 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. > > 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. > > 5. Remove safe_mode and focus on open_basedir > > 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 > > -Rasmus --- ## #17892 — Derick Rethans — 2005-08-12T18:19:04+00:00 URL: https://externals.io/message/17883#17892 · In reply to: #17890 > > […] > > That seems a bit scary, and almost as if it would defeat the purpose. I'm > all for an input filter extension, but it should be one that can't be easily > neutered by (potentially malicious) applications. I wrote up the following spec for this extension: http://files.derickrethans.nl/filter_extension.html Derick --- ## #17893 — Sebastian Bergmann — 2005-08-12T18:19:33+00:00 URL: https://externals.io/message/17883#17893 · In reply to: #17883 Rasmus Lerdorf schrieb: > 1. Remove register_globals completely +1 > 2. Remove magic_quotes_* +1 > 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. +1 > 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. +1 > 6. Remove some stuff that has been marked deprecated since PHP 3/4 +1 > 7. Make identifiers case-sensitive +1 > 8. Remove various function aliases +1 -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #17894 — Pierre-Alain Joye — 2005-08-12T18:23:39+00:00 URL: https://externals.io/message/17883#17894 · In reply to: #17883 Hello, +1 to all things, same comment as the opcode cache Ilia's one. I would like to add one from my wishes: Bump version for the required library as high as possible (or realist) and do not support museum softwares at all, like droping freetype v1 for example. Most of the users do not use it anymore, but it will make the whole much more clean and easier to maintain. --Pierre --- ## #17895 — Antony Dovgal — 2005-08-12T18:26:59+00:00 URL: https://externals.io/message/17883#17895 · In reply to: #17883 I would like to add item #9: * start commenting the code, plz * As long as we don't have any documentation describing internals, comments in the code are something I personally would _really_ like to see. And the more the better. On Fri, 12 Aug 2005 10:48:20 -0700 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. > > 1. Remove register_globals completely > > 2. Remove magic_quotes_* > > 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. > > 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. > > 5. Remove safe_mode and focus on open_basedir > > 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 > > -Rasmus > > -- > > > > -- Wbr, Antony Dovgal --- ## #17896 — Sebastian Bergmann — 2005-08-12T18:29:29+00:00 URL: https://externals.io/message/17883#17896 · In reply to: #17890 George Schlossnagle schrieb: > Radically change all the operator syntaxes. http://www.gravitonic.com/software/php/patches/ze2_concat_obj_op.diff.gz :-) -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #17897 — Ilia Alshanetsky — 2005-08-12T18:32:14+00:00 URL: https://externals.io/message/17883#17897 · In reply to: #17894 This is a very good, point we really should drop support for things like gd1 (no reason anymore, latest versions (including bundled) have GIF support). These only add a hundreds of ifdefs to the code or prevent usage of new(er) functionality. IMHO we should see what is the lowest possible version of a lib distributed by commonly used distro and upgrade our requirements to @ least that version. Ilia Pierre-Alain Joye wrote: > Hello, > > +1 to all things, same comment as the opcode cache Ilia's one. > > I would like to add one from my wishes: > > Bump version for the required library as high as possible (or > realist) and do not support museum softwares at all, like droping > freetype v1 for example. Most of the users do not use it anymore, > but it will make the whole much more clean and easier to maintain. > > --Pierre --- ## #17899 — George Schlossnagle — 2005-08-12T18:48:10+00:00 URL: https://externals.io/message/17883#17899 · In reply to: #17892 > > > > > […] > I wrote up the following spec for this extension: > http://files.derickrethans.nl/filter_extension.html Where's the part about an application swapping back for the raw arrays (as opposed to accessing them specifically as _RAW_GET or whatever)? Or are you and Rasmus talking about two different proposals? George --- ## #17900 — dz@bitxtender.com — 2005-08-12T18:50:47+00:00 URL: https://externals.io/message/17883#17900 · In reply to: #17883 +1 to all of these. I have a #9 to share, too: Assuming that PHP 6.0 will also have namespaces support (which would be cool), it might make sense to move all internal functions to use namespaces (if they support functions sitting in there - doesn't seem like Jessie's current patch will, but then, maybe there's a chance). That way, we could clean up naming inconsistencies (think of all the str* functions), and maybe even some of the common annoyances when it comes to parameter order (haystack, needle vs. needle, haystack) Just a thought. - David > -----Original Message----- > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] > Sent: Friday, August 12, 2005 7:48 PM > To: internals > Subject: [PHP-DEV] PHP 6.0 Wishlist > > 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. > > 1. Remove register_globals completely > > 2. Remove magic_quotes_* > > 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. > > 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. > > 5. Remove safe_mode and focus on open_basedir > > 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 > > -Rasmus --- ## #17902 — Davey Shafik — 2005-08-12T18:56:27+00:00 URL: https://externals.io/message/17883#17902 · In reply to: #17883 As little as it means, +1 - Davey 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. > > 1. Remove register_globals completely > > 2. Remove magic_quotes_* > > 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. > > 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. > > 5. Remove safe_mode and focus on open_basedir > > 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 > > -Rasmus --- ## #17905 — Darrell Brogdon — 2005-08-12T18:57:34+00:00 URL: https://externals.io/message/17883#17905 · In reply to: #17897 Maybe this is too far reaching but what about making function parameter orders consistent? For example, make `in_array()` require in_array(array haystack, mixed needle[...) just as most of the string functions. -D > This is a very good, point we really should drop support for things > like > gd1 (no reason anymore, latest versions (including bundled) have GIF > support). These only add a hundreds of ifdefs to the code or prevent > usage of new(er) functionality. > > IMHO we should see what is the lowest possible version of a lib > distributed by commonly used distro and upgrade our requirements to @ > least that version. > > Ilia > > Pierre-Alain Joye wrote: > > > […] > > -- > > > > Darrell Brogdon darrell@brogdon.net http://darrell.brogdon.net --- ## #17910 — Sara Golemon — 2005-08-12T19:04:04+00:00 URL: https://externals.io/message/17883#17910 · In reply to: #17883 > 1. Remove register_globals completely > Amen! +1 > 2. Remove magic_quotes_* > Hallelujiah! +1 > 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. > Eh... +0 > 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. > Okay... +0 > 5. Remove safe_mode and focus on open_basedir > +1 on dropping safe_mode, and here's a thought for open_basedir. I was thinking about a comment made in another thread... how about open_basedir_child(bool). When enabled, only files at or below the directory in which the current script is executed from may be opened. There may be some SAPIs where this is problematic (since we may not know what directory the file is opened from reliably), but it's worth looking into. > 6. Remove some stuff that has been marked deprecated since PHP 3/4 > Praise non-denominational-diety! +1 Though my definition of "remove" would actually be "migrate to siberia". Whole modules where appropriate. "deprecation" collections where not. > 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 > Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP being (mostly) case-insensitive. > 8. Remove various function aliases > Many of these fall under #6 honestly. I can think of a few that can fall by the wayside. #9... No.... must...resist....four-letter-token....can-of-worms....mmmmggmhghmhhmmhgmhmgm mmm * otherbird sneaks up behind Sara and clamps her mouth shut before the genie is released. --- ## #17911 — Michael Wallner — 2005-08-12T19:07:39+00:00 URL: https://externals.io/message/17883#17911 · In reply to: #17883 Rasmus Lerdorf wrote: [lots of reasonable points] What about moving some/many extensions from core to pecl? Regards, Mike --- ## #17912 — Ilia Alshanetsky — 2005-08-12T19:12:35+00:00 URL: https://externals.io/message/17883#17912 · In reply to: #17911 Jani and Derick have so far done a very good job doing that, I think just about all uncommon extensions have been migrated. But, if something was missed moving it to pecl would be a good idea. Ilia Michael Wallner wrote: > Rasmus Lerdorf wrote: > > [lots of reasonable points] > > What about moving some/many extensions from core to pecl? > > > Regards, > Mike --- ## #17914 — Wez Furlong — 2005-08-12T19:15:04+00:00 URL: https://externals.io/message/17883#17914 · In reply to: #17911 A reasonable goal would be to make sure that all our extensions are full pecl citizens, so that intermediate fixes to any of these so called "core" extensions could be released via PECL very easily. One of the biggest gripes our SA's have is that if they forget to enable a core PHP extension and later need to add it, there is no easy way to pull it in, short of recompiling PHP again. --Wez. > Rasmus Lerdorf wrote: > > [lots of reasonable points] > > What about moving some/many extensions from core to pecl? > > > Regards, > Mike --- ## #17915 — Wez Furlong — 2005-08-12T19:17:28+00:00 URL: https://externals.io/message/17883#17915 · In reply to: #17914 PS: This doesn't necessarily mean that they all need to be physically unbundled from the main distro. --Wez. > A reasonable goal would be to make sure that all our extensions are > full pecl citizens, so that intermediate fixes to any of these so > called "core" extensions could be released via PECL very easily. > > One of the biggest gripes our SA's have is that if they forget to > enable a core PHP extension and later need to add it, there is no easy > way to pull it in, short of recompiling PHP again. > > --Wez. > > > > […] --- ## #17916 — steve roussey — 2005-08-12T19:22:25+00:00 URL: https://externals.io/message/17883#17916 · In reply to: #17883 > 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. I have no karma to +1, but would if I could. It would be wonderful if something like xdebug could profile with op code cache on as well, should it be possible. :) -steve --- ## #17917 — Michael Wallner — 2005-08-12T19:31:35+00:00 URL: https://externals.io/message/17883#17917 · In reply to: #17915 Wez Furlong wrote: > > > > […] > PS: This doesn't necessarily mean that they all need to be physically > unbundled from the main distro. Exactly, couldn't have said that better. Mike --- Next page: https://externals.io/message/17883.md?page=2