[PHP-DEV] PHP 6.0 Wishlist

1 view
Skip to first unread message

Rasmus Lerdorf

unread,
Aug 12, 2005, 1:48:55 PM8/12/05
to
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Derick Rethans

unread,
Aug 12, 2005, 1:54:47 PM8/12/05
to
On Fri, 12 Aug 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.
>
> 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

Andrei Zmievski

unread,
Aug 12, 2005, 2:01:27 PM8/12/05
to
On Aug 12, 2005, at 10:48 AM, Rasmus Lerdorf wrote:

> 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

Ilia Alshanetsky

unread,
Aug 12, 2005, 2:01:57 PM8/12/05
to
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

Gareth Ardron

unread,
Aug 12, 2005, 2:02:43 PM8/12/05
to
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.

George Schlossnagle

unread,
Aug 12, 2005, 2:06:25 PM8/12/05
to

On Aug 12, 2005, at 1:48 PM, 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

+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

Sterling Hughes

unread,
Aug 12, 2005, 2:14:23 PM8/12/05
to
+1 to all things here.

-Sterling

On 8/12/05, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> Since we are breaking a lot of stuff in 6.0, at least with

> Unicode_semantics=3DOn 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.

>=20
> 1. Remove register_globals completely
>=20
> 2. Remove magic_quotes_*
>=20


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

>=20


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

>=20


> 5. Remove safe_mode and focus on open_basedir

>=20


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

>=20


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

>=20
> 7. Make identifiers case-sensitive
>=20


> 8. Remove various function aliases

>=20
> -Rasmus
>=20


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

>=20

Sebastian Bergmann

unread,
Aug 12, 2005, 2:23:34 PM8/12/05
to
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

Pierre-Alain Joye

unread,
Aug 12, 2005, 2:24:25 PM8/12/05
to
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

Antony Dovgal

unread,
Aug 12, 2005, 2:27:32 PM8/12/05
to

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 <ras...@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


>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
Wbr,
Antony Dovgal

Sebastian Bergmann

unread,
Aug 12, 2005, 2:32:35 PM8/12/05
to
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

--

Ilia Alshanetsky

unread,
Aug 12, 2005, 2:33:03 PM8/12/05
to
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
>

--

Wez Furlong

unread,
Aug 12, 2005, 2:44:33 PM8/12/05
to
I agree on all points. Case sensitivity would be nice IMO, but I can
continue to live without it.

--Wez.

On 8/12/05, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> Since we are breaking a lot of stuff in 6.0, at least with

> Unicode_semantics=3DOn 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.

>=20
> 1. Remove register_globals completely
>=20
> 2. Remove magic_quotes_*
>=20

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

>=20


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

>=20


> 5. Remove safe_mode and focus on open_basedir

>=20


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

>=20


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

>=20
> 7. Make identifiers case-sensitive
>=20

> 8. Remove various function aliases

>=20
> -Rasmus
>=20


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

>=20

George Schlossnagle

unread,
Aug 12, 2005, 2:48:56 PM8/12/05
to

On Aug 12, 2005, at 2:19 PM, Derick Rethans wrote:

> On Fri, 12 Aug 2005, George Schlossnagle wrote:
>
>
>>> 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.
>>

> 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

David Zülke

unread,
Aug 12, 2005, 2:51:21 PM8/12/05
to
+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:ras...@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

Davey Shafik

unread,
Aug 12, 2005, 2:57:23 PM8/12/05
to
As little as it means, +1

- Davey

Darrell Brogdon

unread,
Aug 12, 2005, 2:58:25 PM8/12/05
to
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

On Aug 12, 2005, at 12:32 PM, Ilia Alshanetsky wrote:

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

> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


Darrell Brogdon
dar...@brogdon.net
http://darrell.brogdon.net

Michael Wallner

unread,
Aug 12, 2005, 3:07:23 PM8/12/05
to
Rasmus Lerdorf wrote:

[lots of reasonable points]

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


Regards,
Mike

Jessie Hernandez

unread,
Aug 12, 2005, 3:15:07 PM8/12/05
to
David,

Don't know if you read my post from last night, but I played around with
functions in namespaces and they worked (the change was pretty easy). Though
all this allowed was the following:

<?php
namespace test_ns
{
function test_func
{
echo "hello!\n";
}
}

test_func(); // generates an error, 'test_func' does not exist

test_ns:test_func(); // prints "hello!"
?>


So, for your string example, all this would buy is that you'd call
str:replace instead of str_replace (you can use a colon, basically).

As I mentioned in the post, imports do not fit very well for functions, as
the current namespace import logic is handed off to __autoload, and there is
no such thing for functions. Based on the replies, it seems that most would
agree with only allowing classes inside namespaces.

Either way, I was thinking this morning of a simplified syntax to achieve
the "import class/function foo from bar" behavior:

import test_ns:test_class [as other_class_name]; // class import
import test_ns:test_func() [as other_func_name]; // function import
import test_ns:$test_var [as $other_var_name]; // variable imports?? (if
supported)

I personally would just stay with classes. As it is now, if you need a
function that can be used inside a namespace, you can just add a "globals"
class and add a static method there. If you need a namespace-global
variable, you can also just declare a "globals" class and add a public
member variable to it. So only allowing classes inside namespaces is not a
real limitation to begin with.


Regards,

Jessie


"David Zülke" <d...@bitxtender.com> wrote in message
news:B1.AB.3307...@pb1.pair.com...


> +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:ras...@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
> >

Wez Furlong

unread,
Aug 12, 2005, 3:16:32 PM8/12/05
to
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.

On 8/12/05, Michael Wallner <mi...@php.net> wrote:
> Rasmus Lerdorf wrote:
>=20
> [lots of reasonable points]
>=20


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

>=20
>=20
> Regards,
> Mike
>=20


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

>=20

Wez Furlong

unread,
Aug 12, 2005, 3:17:54 PM8/12/05
to
PS: This doesn't necessarily mean that they all need to be physically
unbundled from the main distro.

--Wez.

On 8/12/05, Wez Furlong <kin...@gmail.com> wrote:
> 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.

>=20


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

>=20
> --Wez.
>=20


> On 8/12/05, Michael Wallner <mi...@php.net> wrote:
> > Rasmus Lerdorf wrote:
> >

> > [lots of reasonable points]


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

> > Regards,
> > Mike

steve roussey

unread,
Aug 12, 2005, 3:22:51 PM8/12/05
to
> 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--

Davey Shafik

unread,
Aug 12, 2005, 3:36:56 PM8/12/05
to
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

--

Marco Tabini

unread,
Aug 12, 2005, 3:37:54 PM8/12/05
to

On 8/12/05 2:50 PM, "David Z=FClke" <d...@bitxtender.com> wrote:
> 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 namespac=

es
> (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 ma=

ybe
> even some of the common annoyances when it comes to parameter order
> (haystack, needle vs. needle, haystack)
>=20

I thought about suggesting this (or something like it)... But unlike
anything that Rasmus has suggested, doing this will be dramatically
destabilizing to *every* single PHP script, unless the platform also
maintains a massive alias list--which is of course what Rasmus was trying t=
o
get rid of anyway :)


Mt.

David Zülke

unread,
Aug 12, 2005, 3:38:55 PM8/12/05
to
Duh... "internal functions" is the wrong term, of course. I mean all the
functions that ship with PHP. The old ones would still be available, but =
you
could do PHP.String.pos() and stuff like that alternatively.

- David


> -----Original Message-----
> From: David Z=FClke [mailto:d...@bitxtender.com]
> Sent: Friday, August 12, 2005 8:51 PM
> To: 'internals'
> Subject: RE: [PHP-DEV] PHP 6.0 Wishlist
>=20
> +1 to all of these.

>=20
> 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)
>=20

> Just a thought.
>=20
> - David
>=20
>=20


> > -----Original Message-----
> > From: Rasmus Lerdorf [mailto:ras...@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=3DOn 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
> >

> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >

>=20


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

>=20

Ilia Alshanetsky

unread,
Aug 12, 2005, 3:45:38 PM8/12/05
to
> 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)

-1 to namespaces. As for modifying functions that would require a fair
number of function aliases for BC as untold number of scripts will
break. That is something we are trying to eliminate in the first place.


Ilia

Sara Golemon

unread,
Aug 12, 2005, 3:46:10 PM8/12/05
to
> 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.

Michael Wallner

unread,
Aug 12, 2005, 4:11:09 PM8/12/05
to
Wez Furlong wrote:

> On 8/12/05, Wez Furlong <kin...@gmail.com> wrote:
>
>>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.

> 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

Ron Korving

unread,
Aug 12, 2005, 4:13:00 PM8/12/05
to
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

Derick Rethans

unread,
Aug 12, 2005, 4:19:40 PM8/12/05
to
On Fri, 12 Aug 2005, George Schlossnagle wrote:

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

I wrote up the following spec for this extension:
http://files.derickrethans.nl/filter_extension.html

Derick

Ilia Alshanetsky

unread,
Aug 12, 2005, 5:13:04 PM8/12/05
to
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
>

--

Sara Golemon

unread,
Aug 12, 2005, 5:16:37 PM8/12/05
to
> How about doubling integer precision to 64 bits and float/double precision
> to 128 bits? It's in line with 64 bit CPU capabilities, and personally, I
> wouldn't mind it a bit if it would make numerical processing in PHP slower
> on 32 bit systems. I think the advantages are much too great for that. If
> this is ever gonna happen, I think PHP6 would be great timing for it.
>
If there were such a type as 'zend_long' used universally that might be at
least possible (even configurable as a compile-time switch), but as it is
*EVERYTHING* that touches a zval expects a long. On 32bit platforms that's
a 32-bit number and there's no trivial way to change that.

Athlon64s and Opterons are cheap nowadays anyway. I picked up a MB/CPU
combo at Fry's last week for like $200.

-Sara

Pierre-Alain Joye

unread,
Aug 12, 2005, 5:33:15 PM8/12/05
to
On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
sni...@iki.fi (Jani Taskinen) wrote:

>
> Very good idea. We do bundle the thing? :)

I do not think we can use the extern GD2 in the same nice way than
we use ours.

But droping _extern_ gd2 support is possible. The only remaining
thing is to check that we will be really binary compatible.

Regards,

--Pierre

Andrey Hristov

unread,
Aug 12, 2005, 5:41:33 PM8/12/05
to
+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

Jani Taskinen

unread,
Aug 12, 2005, 6:02:00 PM8/12/05
to

Very good idea. We do bundle the thing? :)

--Jani

On Fri, 12 Aug 2005, Ilia Alshanetsky wrote:

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

--

Lukas Smith

unread,
Aug 12, 2005, 6:33:47 PM8/12/05
to
+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

Jani Taskinen

unread,
Aug 12, 2005, 6:56:52 PM8/12/05
to
On Fri, 12 Aug 2005, Pierre-Alain Joye wrote:

> On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
> sni...@iki.fi (Jani Taskinen) wrote:
>
>>

>> Very good idea. We do bundle the thing? :)
>

> I do not think we can use the extern GD2 in the same nice way than
> we use ours.
>
> But droping _extern_ gd2 support is possible. The only remaining
> thing is to check that we will be really binary compatible.

I don't think dropping the external library linking support
is such a good idea. Just nuke GD1 support.

(gotta start somewhere :)

--Jani

Jani Taskinen

unread,
Aug 12, 2005, 7:03:52 PM8/12/05
to
On Fri, 12 Aug 2005, Rasmus Lerdorf wrote:

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

Lukas Smith

unread,
Aug 12, 2005, 7:24:15 PM8/12/05
to
Ron Korving wrote:

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

IIRC George once played around with a few peekhole optimizations for
APC. I think the performance improvements possible with peekhole
optimizations are probably not that great in the real world.

However its a kind of atttractive thought to have frequently accessed
cached code in APC being optimized more aggressively the more the code
is being uses. AFAIK the Zend Performance Suite (or whatever it is
called today) does that.

regards,
Lukas

Marcus Boerger

unread,
Aug 12, 2005, 7:24:53 PM8/12/05
to
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

Marcus Boerger

unread,
Aug 12, 2005, 7:44:06 PM8/12/05
to
Hello Sebastian,

why is this on gravitonic.com ?

anyway. If we'd use the VBA operator for that then we could use the '.'
for namespaces and wouldn't run into any trouble with namespaces at all.
Besides someone wanted to have functions in namespaces.

marcus

Friday, August 12, 2005, 8:29:29 PM, you wrote:

> 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

Wez Furlong

unread,
Aug 12, 2005, 8:12:10 PM8/12/05
to
We definitely need to start thinking forward and introduct a 64-bit
type. It needn't replace the 32-bit type.

IIRC, Andi promised that we would have this after 5.1, so I think it's
a done deal.

It's especially important now that we have a number of extensions
returning 64-bit data.
And with Visual Studio .Net 2005, time_t is now 64-bit (!?)

--Wez.

On 8/12/05, Sara Golemon <pol...@php.net> wrote:
> > How about doubling integer precision to 64 bits and float/double precis=
ion
> > to 128 bits? It's in line with 64 bit CPU capabilities, and personally,=
I
> > wouldn't mind it a bit if it would make numerical processing in PHP slo=
wer
> > on 32 bit systems. I think the advantages are much too great for that. =


If
> > this is ever gonna happen, I think PHP6 would be great timing for it.
> >

> If there were such a type as 'zend_long' used universally that might be a=


t
> least possible (even configurable as a compile-time switch), but as it is

> *EVERYTHING* that touches a zval expects a long. On 32bit platforms that=


's
> a 32-bit number and there's no trivial way to change that.

>=20


> Athlon64s and Opterons are cheap nowadays anyway. I picked up a MB/CPU
> combo at Fry's last week for like $200.

>=20
> -Sara
>=20


> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

>=20

Lukas Smith

unread,
Aug 12, 2005, 8:15:14 PM8/12/05
to
Marcus Boerger wrote:

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

could you elaborate what you mean with this ..

currently (some?) "static" calls from within a method will still result
in a non static method call ... like parent::fobar()

are you talking about cleaning this up?

also do you remember my complaints about the fact that static and
inheritance dont mix well, since alot of things are done at compile time
for performance reasons .. does this also fall into this topic?

regards,
Lukas

Marcus Boerger

unread,
Aug 12, 2005, 8:31:31 PM8/12/05
to
Hello Lukas,

Saturday, August 13, 2005, 1:34:35 AM, you wrote:

> Marcus Boerger wrote:

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

> could you elaborate what you mean with this ..

> currently (some?) "static" calls from within a method will still result
> in a non static method call ... like parent::fobar()

> are you talking about cleaning this up?

static=static, non-static=non-static and no moe ZEND_ACC_ALLOW_STATIC

> also do you remember my complaints about the fact that static and
> inheritance dont mix well, since alot of things are done at compile time
> for performance reasons .. does this also fall into this topic?

well you could make your own oint in disallowing "if() class" or in other
words allow class definitions only in the main block. If then you go for
forward declarations also "class SomeClassName; /* no block after ; */"
you'd gain a bit:

- being able to use upcoming perl 6 compiler namely parrot (if someone
wants to do the work). Full support with upcoming php idl compiler. But
we have to hear about that from the author.

- moving all inheritance to compile time - already a tiny bit of a spead
increase - together with apc or some other cache another bit of a speed
increase.

On the contray you'd loose some flexibilty (not that i'd like it buut
others do) and btw php is the only language in use i knwo of which is
capable of this.

best regards
marcus

Rui Hirokawa

unread,
Aug 12, 2005, 9:29:33 PM8/12/05
to

+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 <ras...@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_hi...@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

Ron Korving

unread,
Aug 12, 2005, 9:41:09 PM8/12/05
to
Oh, and I almost forgot one wishlist item I've had on my list for a long
time (I hope you guys have an open mind)........

How about doubling integer precision to 64 bits and float/double precision
to 128 bits? It's in line with 64 bit CPU capabilities, and personally, I
wouldn't mind it a bit if it would make numerical processing in PHP slower
on 32 bit systems. I think the advantages are much too great for that. If


this is ever gonna happen, I think PHP6 would be great timing for it.

It would make falling back to the slow string-based bc match functions a lot
less common. Personally, I really like the idea of being able to count to
9223372036854775808 instead of 2147483648.

Ron

Marco Tabini

unread,
Aug 13, 2005, 12:07:55 AM8/13/05
to
Hey Ilia,

On 8/12/05 3:03 PM, "Ilia Alshanetsky" <il...@prohost.org> wrote:
>
> -1 to namespaces. As for modifying functions that would require a fair
> number of function aliases for BC as untold number of scripts will
> break. That is something we are trying to eliminate in the first place.
>


With namespaces, wouldn't the problem go away altogether? Old function names
can be deprecated and E_STRICT'ed and a new, uniform naming convention and
parameter order be enforced for the future. I hate namespaces but this
sounds like a good solution to me.


Mt.

Ryan King

unread,
Aug 13, 2005, 12:16:57 AM8/13/05
to

On Aug 12, 2005, at 3:33 PM, Lukas Smith wrote:

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

PHP_Compat[http://pear.php.net/package/php_compat] would be another
alternative.

-ryan

> Speaking of *kit .. how about sandboxing or some sort of taint model.
>
> regards,
> Lukas
>

Alan Knowles

unread,
Aug 13, 2005, 12:26:46 AM8/13/05
to
How about running from serialized opcode memory block (rather than array
of struct'd opcodes...), so writing a thread extension is alot easier ;)

Oh well, I can always dream...

Regards
Alan

On Fri, 2005-08-12 at 23:27 -0400, Marco Tabini wrote:
> Hey Ilia,
>
> On 8/12/05 3:03 PM, "Ilia Alshanetsky" <il...@prohost.org> wrote:
> >
> > -1 to namespaces. As for modifying functions that would require a fair
> > number of function aliases for BC as untold number of scripts will
> > break. That is something we are trying to eliminate in the first place.
> >
>
>
> With namespaces, wouldn't the problem go away altogether? Old function names
> can be deprecated and E_STRICT'ed and a new, uniform naming convention and
> parameter order be enforced for the future. I hate namespaces but this
> sounds like a good solution to me.
>
>
> Mt.
>

--

Sebastian Bergmann

unread,
Aug 13, 2005, 1:11:15 AM8/13/05
to
Marcus Boerger schrieb:

> why is this on gravitonic.com ?

Ask Andrei, it's been there for ages.

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

--

Ilia Alshanetsky

unread,
Aug 13, 2005, 2:26:11 AM8/13/05
to
Why would I need name spaces for basic functions, just so that I need to
rename all my code to use str:replace rather then str_replace and
perform 2 hash table lookups?

Ilia

Marco Tabini wrote:
> Hey Ilia,
>
> On 8/12/05 3:03 PM, "Ilia Alshanetsky" <il...@prohost.org> wrote:
>
>>-1 to namespaces. As for modifying functions that would require a fair
>>number of function aliases for BC as untold number of scripts will
>>break. That is something we are trying to eliminate in the first place.
>>
>
>
>
> With namespaces, wouldn't the problem go away altogether? Old function names
> can be deprecated and E_STRICT'ed and a new, uniform naming convention and
> parameter order be enforced for the future. I hate namespaces but this
> sounds like a good solution to me.
>
>
> Mt.
>
>
>
>

--

Ilia Alshanetsky

unread,
Aug 13, 2005, 2:30:30 AM8/13/05
to
Marcus Boerger wrote:
> 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.

Can you clarify that?

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

-1 before, -1 still.

> 12. {} vs [] cleanup

unicode support already makes such distinction it.

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

One hand I like it, I think I even proposed things like $str{-1} at one
time, on the other hand it creates a big WTF factor. Overall I'd say, -0.5

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

-1

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

+1 for pecl move, ~0 for the rest.

Ilia

Andrei Zmievski

unread,
Aug 13, 2005, 3:34:58 AM8/13/05
to
We did, but we never arrived at consensus. I don't really see a good
reason for giving people access to code-units with such a low-level
operator. If we fix it, I'd rather fix it so that [] only works on
arrays, and {} on strings, with some sort of BC switch.

-Andrei


On Aug 12, 2005, at 11:47 PM, Ilia Alshanetsky wrote:

> I thought we've discussed making one access code-units and the other
> code-points?
>
> Ilia
>
> Andrei Zmievski wrote:


>
>> On Aug 12, 2005, at 11:29 PM, Ilia Alshanetsky wrote:
>>
>>
>>>> 12. {} vs [] cleanup
>>>>
>>>>
>>>
>>> unicode support already makes such distinction it.
>>>
>>
>>

>> No, it doesn't. That's one of the thorny unresolved issues.
>>
>> -Andrei

Xuefer

unread,
Aug 13, 2005, 4:01:10 AM8/13/05
to
i'd suppose u guys going to deprecate+E_STRICT first, remove later


> > George Schlossnagle schrieb:
> >> Radically change all the operator syntaxes.

>=20
> > http://www.gravitonic.com/software/php/patches/ze2_concat_obj_op.diff.=
gz
>=20
FYI: _ is validate char in variable/function name
_("Hello! world"); // gettext
define('_', 1);
echo _;

On 8/13/05, Marcus Boerger <he...@php.net> wrote:
> Hello Sebastian,
>=20


> why is this on gravitonic.com ?

>=20


> anyway. If we'd use the VBA operator for that then we could use the '.'
> for namespaces and wouldn't run into any trouble with namespaces at all.
> Besides someone wanted to have functions in namespaces.

>=20
> marcus
>=20


> Friday, August 12, 2005, 8:29:29 PM, you wrote:

>=20
VB use & for string concat. they said & is faster as + is used for
number addition. flash4 actionscript use another magic looking
operator but changed to "." in v5 too
looks like there's no more single character for "string concat"
operator for php if u take the dot away. lua use double dot.


i saw some code written as:
$myarray[def] =3D $HTTP_GET_VARS[abc];
both abc and def is not constant. it seems they're wishing to use
$myarray.def while they hate $myarray["def"], but can only use
$myarray[def] instead. untill they recognized there's a warning as def
is treat as constant first.
why the hell we can use "." or something else simple for frequent
purpose (array value/obj property)
the way javascript do looks quite simple. both "." and "[]" can access
array/object

anyway, they can't +1 for this as it break all scripts with hardly a hack f=
or BC

Ondrej Ivanič

unread,
Aug 13, 2005, 5:08:37 AM8/13/05
to
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
(ond...@kmit.sk)

David Zülke

unread,
Aug 13, 2005, 5:56:11 AM8/13/05
to
> > 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.)
>
> -1 before, -1 still.

Well... if you're so anti-namespaces, I'm sure you will change all my code
to use different names when collisions occur, right? Thanks man, saves me
loads of trouble then.

- David

Ilia Alshanetsky

unread,
Aug 13, 2005, 7:27:59 AM8/13/05
to
I thought we've discussed making one access code-units and the other
code-points?

Ilia

Andrei Zmievski wrote:
> On Aug 12, 2005, at 11:29 PM, Ilia Alshanetsky wrote:
>
>>> 12. {} vs [] cleanup
>>>
>>
>> unicode support already makes such distinction it.
>
>
> No, it doesn't. That's one of the thorny unresolved issues.
>
> -Andrei
>

--