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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
