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

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

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

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.

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

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

+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

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

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

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 rasmus@lerdorf.com 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

+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

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

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.

Rasmus Lerdorf wrote:

[lots of reasonable points]

What about moving some/many extensions from core to pecl?

Regards,
Mike

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

Now I'm not the person with the kind of karma that should make you guys
listen, but in case you are interested, I'll just add my 2 cents

1. Remove register_globals completely

+1

2. Remove magic_quotes_*

+1000

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

+1
Althought perhaps it could remain case-insensitive, but throwing a notice.
This way users can decide for themselves if they wanna write neat code by
using E_ALL. On the other hand, I assume case sensitivity would improve
overall performance, while notices do the exact opposite.

8. Remove various function aliases

+1

-Rasmus

Might I add a few requests:

9. Much improved __toString behavior (I doubt I'd need to clarify that)

10. Broader support for (custom) stream-wrappers (I noticed the zlib
    functions don't accept them). I wanted to make a stream wrapper for strings,
    so I could do this: readgzfile("str://andHereSomeGzipData").. In fact, if
    you ask me, such a str:// wrapper may be implemented as a standard wrapper.
    It would be useful in a lot more cases where functions read from files.

11. Altered/improved garbage collection (see my recent post on leaking
    memory when throwing exceptions from a foreach() loop). Leaking memory may
    be perfectly fine in a webserver situation, but I personally use PHP a lot
    for cli-scripts (sometimes forever-running daemon applications) and I'm sure
    a lot of other people do as well.

12. I hate to bring this up, don't shoot me for this, but ... multiple
    inheritance? ;)

13. A built-in code optimizer. Why should something like Zend optimizer be
    installed afterwards, if everybody can use increased performance?

14. Turn (all) fatal errors in extentions and the core into exceptions.
    Personally, I'd like to be able to catch and log all error situations, not
    just the ones I create myself. The exceptions should be of a specific custom
    exception class of course. If people don't catch the exceptions, the output
    would be pretty much as the same as fatal errors are right now anyway, so BC
    won't really be a problem.

15. Remove $HTTP_* (altho you may have included that when you thought of #6)
    and register_long_arrays.

16. Support for <?php="foo" ?>

17. A reliable non-bankers-round function

18. The ability to use an array() of constants in a define.

Maybe I'll think of more later ;)

Ron

1. Remove register_globals completely

 +1 (then we can cleanup the mess in ext/session too :)

2. Remove magic_quotes_*

 +1 (definately, finally, at last! The filter stuff obsoletes those anyway?)

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 (to be able to do 2. for real, of course)

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.

 +100 (it's ridiculous to have to install it separately)

5. Remove safe_mode and focus on open_basedir

 +1

6. Remove some stuff that has been marked deprecated since PHP 3/4

 Something like 'allow_call_time_pass_reference' or whatever it was again?

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

 Such as function names? :) That'd be kinda nice since it not only
 makes the language more consistent but also tad faster, especially
 now with the unicode stuff slowing that down even more..

8. Remove various function aliases

 I was toying with an idea about a configure switch and/or ini option.
 But I guess some of those just should go away.

 The other wild idea I got while thinking about this was to add
 opposite option for 'disable_functions', 'enable_functions', which
 would only enable the functions I _really_ use :)

 --Jani

+1 from here too except 0 for the case sensitivity.

Andrey

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

+1 on all the mentioned items, except for case sensitivity for
identifiers where I am -1 (I dont see the benefit).

Aside from that I wouldnt mind an aggressive function name and parameter
order clean up. We could provide a BC lib via runkit (or was it classkit
.. I can never separate the two in my brain).

Speaking of *kit .. how about sandboxing or some sort of taint model.

regards,
Lukas

Hello Rasmus,

Friday, August 12, 2005, 7:48:20 PM, you 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
   +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

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
   +10

8. Remove various function aliases
   ~0

-Rasmus

Very nice list. Very nice list.

May i continue with a few additions of mine by order of importance?

9. __toString) everywhere, but i already said i'll take care of that unless
   i am being held back. So now go for that or live with the fact that php is
   meant to generate html pages which is text output. Thus sooner or later your
   objects create text simplifying that aas much as possible is at least to me
   mor ethan welcome.

10. namespace support (we are telling everyone php is ready for the big
    soup. In those scenarios you often find big teams and any help allowing
    things like dedicated responisbilities and preventing communication
    problems is more then welcome.)

11. class operator cleanup
    :: static
    -> non static
    this would allow to do more things like accessing static members/consts
    from anywhere a class is allowed etc. (if proposed that before incl. patch
    lookup the archieves).

12. {} vs [] cleanup

12a. using {} for strings could also bring us substr() functionality to {}.

13. eventually cleanup parameter order. Guys who knows in which functions
    the needle is first or second? My solution is to look up every function
    always which is a bit inefficient. I know the param order in c/C++ and
    sometimes in java but in php storing that info is impossible and useless so
    far.

14. i read drop gd1, nice one

15. i think of splitting dba, making ini-file into dba core and putting all
    but dba core into pecl (further plans for ini-file).

16. changing var_dump() et all to write out the class name for members since
    it is not helpfull at all if you see two members of the same name. Maybe it
    helps if one is private and the is not but still ....

And i already treated "the operator which must not be named" for somethig
else so there is no 17 here. Wow you made it till here.

My favorites are actually: 7, 4, 3, 9, 10, 11, 1, 2, 5, 6, 12, 13, 14,15, 16

I consider most of the above actually as bugs: "Whipe them out all of them".

Best regards,
Marcus

+1 bundling the opcode cache like APC.

I also wish some elemental debugging features (stack dump, etc.)
like Xdebug has.

Rui

On Fri, 12 Aug 2005 10:48:20 -0700
Rasmus Lerdorf rasmus@lerdorf.com 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.

--
Rui Hirokawa rui_hirokawa@ybb.ne.jp

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 2005/08/12

Hi

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

+1 to all things here.

9. Shared memory storage for variables with transparent access.
   (superglobal array?)

--
Ondrej Ivanic
(ondrej@kmit.sk)

Rasmus Lerdorf wrote:

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.

Big +1

9. Named parameters. Preferred way would be via array()-less array
   collation as we are already using this in our production system ;-) :
   foo('id' => 42, 'name' => "foo");

10. Allow dangling commas in function calls, handy with varargs and 9:
    foo(1, 2, 3,);

Minor:

11. HTTP response splitting attack protection: Replace \r and \n with
    space in header();

Information and patches implementing this can be found at
http://cschneid.com/php/

• Chris

Hi,

On Fri, 12 Aug 2005 10:48:20 -0700, in php.internals
rasmus@lerdorf.com (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.

I know this is just a wish list, and it wouldn't be constructive to go
into implementation details. As you said, this is cleanup where some
eggs will have to break.

FWIW, as many others, I'm mainly positive about all the changes. Not
surprisingly there would be a bunch of work regarding the information
to end users. This might require some political decisions on what to
recommend, when "features" are removed from users.

I'll go into details here:

1. Remove register_globals completely

2. Remove magic_quotes_*

I'm all for. It would be nice, though, to provide users with details
on how to do it "the right way" regarding database queries.

Even though there are a lot of ways of doing it (manually call
mysql_real_escape_string, use PEAR DB, use another API, etc.)., it
might be nice to show users a simple way of doing stuff. I really like
the perl DBI which is the de facto way of doing database work. I
believe that lots of stuff that DBI (and PEAR DB and other DB
abstraction layers) provide is helpful. Crafting and concatenating a
query string really is a mess.

On one hand this might have nothing to do with the tools and more on
recommendations on how to code. It might not be the job of the PHP
team to teach users how to code or recommend specific ways to code
(think of all the OOP- and exception handling-discussions).
Furthermore people might have different views on what API to use. I
like PEAR DB because it is widely used, but as an example I don't like
the chicken-and-the-egg problem (DB_common only gets read when
DB::Connect has been called and loaded, så DB_common can't be
extended). The point is mainly that it would be hard to recommend one
way of doing things now (and it might be a political decision as
well).

On the other hand, people will be in demand of
"how-to-convert"-information in the transitional phase. And if we
really are doing a spring cleanup, we might consider doing it on the
users 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.

This might go in hand with the first two wishes. It would be nice to
make it easy for users who write php code that are going to be
distributed world wide on different configurations without going into
hundreds of different checks (such as "if (get_magic_quotes_gpc()) {
.. }" ).

5. Remove safe_mode and focus on open_basedir

I think a lot of work would have to go into this. Currently <warning type="pet peeve"> it could partially be circumvented using glob, e.g.
print_r(glob("{/home/currentuser/,/etc}/*",GLOB_BRACE)); or error
harvesting ("File(/tmp/sess_1234567890) is not within the allowed
path(s)") </warning>

I'm not sure whether or not this is regarded as a problem. These
issues have been dismissed on the bugs list and I haven't heard
anything from security@.

Another type of default session handler might also be nice without
direct mapping of file names and session ids - e.g. hashed values and
addition of hashed SERVER_NAME where available.

Regarding the way users code (as mentioned in #3), we also see that
when notices were enabed and widespread on installations, e.g.:
if ($_REQUEST['foo'] == ...)

.. users just changed their code to:
if (isset($_REQUEST['foo']) && $_REQUEST['foo'] == ...)

I don't think this is particular more nice code, but just a recurring
pattern every time a variable from the outside is submitted. This is a
really wild idea, but how about retrieving external variables using
functions instead? The idea is that external data isn't variables per
default and could be referenced without throwing notices, e.g.:

if (getuserdata('foo') == ...)

Of course I'm not against notices, but I think there is a clear
distinction (or should be...) between stuff that might exist beyond
our control (user-submitted data) and stuff that we rely on (own
variables).

But all in all: very exciting. As mentioned, there really might be a
lot of work regarding the information and transitional help if all
these wishes come true.

--

• Peter Brodersen

for what its worth - brilliant :-)

aftering reading the remarks about perl6 (love the idea of
you guys winning that 'race' :-) I did a little reading, seems
perl6 is aimed to target Parrot... I remember there was discussion
about this for php, don't know if the idea died a lonely death or
was just put in the deepfreeze - maybe it's something to consider?

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

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.

How about allowing mod_php6 to run alongside mod_php? Provide an easy
way for the hosting people to provide PHP6 without breaking everything.

Aaron

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

Just my 2 cents :

9. I don't know current status of apache_hooks
   (http://cvs.php.net/php-src/sapi/apache_hooks/) but it would be nice to
   make it stable with good documentation on php.net

10. make standarts for function's names.
    For example php has str_replace() and strpos(). I think last function
    should be named str_pos().
    But if namespaces will be added to internal functions (str:replace,
    str:pos) it will be unnesseccary.

11. +1 namespaces

12. disable @ via settings

13. add keyword 'finally' to exceptions

Rasmus Lerdorf :

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

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.

This is a sweet carrot to drive adoption despite a few minor BC issues.

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

+100 for Unicode support

1. Remove register_globals completely

+1

2. Remove magic_quotes_*

+100 (any "magic" is bad in the long run, see Perl)

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.

+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.

5. Remove safe_mode and focus on open_basedir

+0.5 I think that safe_mode and similar kludges and hinges really
shouldn't be in any language. OS needs to provide the security we
need, it cannot safely be added at some higher level.

As what to comes to renaming old function I don't like it. I've been
hit with minor stuff like changing pgsql_numrows to pgsql_num_rows()
in a minor release and even though there's an easy fix, it still not
worth it. If you want to fix not-so-well named functions like
in_array() or strstr() put the fixed functions in a new namespace or
add a suffix like, for example, 2. So PHP6 could have

strpos(haystack,needle)
strpos2(needle,haystack)
str:pos(needle,haystack)
str::pos(needle,haystack)

or some combination of above, but PHP6 should not have

strpos(needle,haystack).

If I were to decide, I would move all the old functions to new names
into new namespaces and include a wrapper files with public domain
license so that it could be freely modified as required. The PD
licensed files contained just code like

compatibility/str.php:
....
function strpos(haystack,needle)
{
return str::pos(needle,haystack);
}
....

and the old code that required the old functions could just add
require_once("compatibility/str.php"); in required files. That is,
rename the functions as seen best and provide compatibility code in
user space to make the old code work without big changes.

In addition, I'd change following:

• Handle incoming parameters and data better. According to HTTP
  specification, an URL can contains stuff like
  "...foo=1&foo=2&foo=3..." and I should be able to extract those
  values without having "[]" in every parameter name. See <select multiple> or <input type="file">, for example. I'd prefer "array
  query_param(param_name,method)" which returned an array of values
  for parameter named according to param_name. The optional method
  parameter is used to select GET, POST, DELETE, PUT or whatever. By
  default method would be ANY which would be interpreted as
  GET,POST,PUT,DELETE,COOKIE meaning return stuff sent with GET
  protocol first, followed by stuff sent by POST protocol and so on. I
  think GET should be used first because it's easiest to change. It is
  not a security feature to use COOKIE first because it can be
  modified almost as easily as GET. Debugging and workarounding
  different bugs is just harder if GET doesn't override values set by
  other means.

• Improved file uploads. Make it possible for a PHP script to
  decline an upload before it has been completed. Make it possible
  to handle big uploads without requiring uploaded file to fit the
  memory. Handle multiple file uploads with the same name better than
  now. $_FILES['fieldname'][1]['filename'] if far from a good solution
  and even that works only if field is really named "fieldname[]".

• Better error reporting. As I cannot capture ALL errors (including
  parse errors and friends) with user defined error handlers I need
  much better error messages to system log by default. At least
  exact time (perhaps down to microsecond?), back trace, error
  location (and in case it was eval()ed code, the location of eval()
  call - or locations of eval() calls if they were nested) would be
  required in addition to currently logged information.

• Anonymous functions. The real stuff, not just some odd string
  passed to create_function().

--
Mikko

Hi:

It would be nice if PHP could not get tripped up by "<?xml" tags when
short_tags is on.

http://bugs.php.net/bug.php?id=25987

--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

It's unclear to me what the position of the big kahuna's is on the following
issues, but I hope they can become a reality in PHP6:

1. named parameters.
   in user functions, but also in core functions:
   $result = in_array(needle: "foo", haystack: $array);

2. error reporting using exceptions.
   I would like it if I could catch PHP-errors and take appropriate action
   (such as logging it to a database or whatever).

3. doubling the precision of integers to 64 bits and floats to 128 bits.
   I know Wez wants this too, but will it happen? I think it would be nice if
   it would be a transparant change and the standard types would simply have a
   bigger range.

4. improved __toString behavior

5. Altered/improved garbage collection (see my recent post on leaking memory
   when throwing exceptions from a foreach() loop). Leaking memory may be
   perfectly fine in a webserver situation, but I personally use PHP a lot for
   cli-scripts (sometimes forever-running daemon applications).

6. Broader support for (custom) stream-wrappers (I noticed the zlib
   functions don't accept them). I wanted to make a stream wrapper for strings,
   so I could do this: readgzfile("str://andHereSomeGzipData").. In fact, if
   you ask me, such a str:// wrapper may be implemented as a standard wrapper.
   It would be useful in a lot more cases where functions read from files.

Thanks,

Ron

Rasmus Lerdorf schrieb:

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.

In case we include APC by default, it would be nice if its apc_store() /
apc_fetch() mechanism could be mapped to a new super-global, say
$_PERSISTENT[].

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Where does using case sensitive identifiers fall?

As something of a dream, without the additional infrastructure that
George described.

Personally, I don't really mind if we get case sensitivity or not; the
other items on Rasmus' list all seem very reasonable and (with the
exception of magic_quotes_runtime) can be pretty easily emulated in
user-space.

The filter ext's new specs have a filter for that now.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Zeev,

"Real" anonymous functions (as in, closures) should be able to capture
variables from its lexical environment, e.g.:

create_function() accepts a string, and that string is constructed with
full access to the lexical scope of the creating function, so I'm not
exactly sure how it's different. My ML/LISP memory fails me.

I misread. The obvious difference is that you're not creating code
strings in ML/LISP, so (1) you can avoid all kind of error-prone
marshalling and (2) you can compile the function at compile-time and
simply fill out its free variables when "instantiating" the closure
(using the current lexical environment), giving you syntax checks &
performance.

I intentionally phrased that sentence to resemble object
instantiation: In fact it's pretty much the same thing with more less
verbose/local syntax! I.e. as I believe you said, it is certainly
not a question of how/whether we want that functionality, but
whether we want to encourage this particular style of programming.

Cheers,
Michael

Can't help it... ;) By the way, I thought all programmers were lazy to some
extent?

Seriously though, I think it would be nice and consistent if it would work.
I just really like the short <?= syntax.

Ron

"Joseph Crawford" codebowl@gmail.com wrote in message
news:8d9a428005083106202fa3d5ea@mail.gmail.com...
Why do you find the need to be lazy and use <?=$foo?> lol j/k

i always use <?php echo $foo; ?> it may be only a few more chars of code but
it is guranteed to work on any php installation ;)

--
Joseph Crawford Jr.
Codebowl Solutions, Inc.
1-802-671-2021
codebowl@gmail.com

			<?=$var?> is much much better then <?php echo $var ?> because
			it is shorter and gives a more readable code. And I am
			sure that more than a half of the PHP programmers can confirm
			that. <?php= $var ?> becomes very long too. The compatibility
			issue is quickly resolved by global replacing '<?=' with
			'<?php echo' so it is actually a minor problem.

Ron Korving wrote:

I have another idea I came up with today: regular expression switches, but
it would be difficult without adding to the syntax.

no, its actually pretty easy from a syntax point of view,
you don't need to add another keyword, just add an optional
callback parameter to switch() which is a comparison function
similar to what you pass to e.g. usort()

that way you are not limited to one type of reges but could
have ereg or preg style or could do other things like case
insensitive switches:

switch ($str, "ereg") {
case "[[:alpha:]]+":...
}

switch ($str, "preg_match") {
case "/^[A-Za-z]+$/": ...
}

switch ($str, "strcasecmp") {
...
}

or even

function my_cmp($str1, $str2) {
return strcmp(str_rev($str1, $str2));
}

switch ($str, "my_cmp") ...

i have looked into implementing that quite a while ago
but hat to give up due to lack of time and understanding
at that point in time though

Can be done already ... sorta.

switch (true) {
case ($str == 'abc'):
echo "it was ABC!\n";
break;
case (preg_match('/^[0-9]+$/i', $str)):
echo "it was a number!\n";
break;
default:
echo "it was no number :-(\n";
break;
}

shrug

-james

Ron Korving wrote:

I have another idea I came up with today: regular expression switches, but
it would be difficult without adding to the syntax.

switch ($str)
{
case "abc":
echo "it was ABC!\n";
break;

regcase "/^[0-9]+$/i":
echo "it was a number!\n";
break;

default:
echo "it was no number :-(\n";
break;
}

Just an idea ;)

Ron