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.
-
Remove register_globals completely
-
Remove magic_quotes_*
-
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. -
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. -
Remove safe_mode and focus on open_basedir
-
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:
-
Make identifiers case-sensitive
-
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.
- Remove register_globals completely
+1
- Remove magic_quotes_*
+1
- 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
- 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
- Remove safe_mode and focus on open_basedir
+1 (I'd say remove both though ;-)
- 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:
- Make identifiers case-sensitive
You mean: make all identifiers case-sensitive? (Currently varnames are
already case-sensitive). If you meant all:
+1
- Remove various function aliases
+1
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
- Remove register_globals completely
Yes.
- Remove magic_quotes_*
Yes. Nothing but trouble, this one.
- 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.
- 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.
- Remove safe_mode and focus on open_basedir
Yes.
- 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:
- 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..
- Remove various function aliases
Could be nice to clean up.
-Andrei
Rasmus Lerdorf wrote:
- Remove register_globals completely
+1
- Remove magic_quotes_*
+1
- 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).
- 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.
- Remove safe_mode and focus on open_basedir
+1
- 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.
- Remove various function aliases
That closely relates to 6, so same comments apply.
Ilia
Rasmus Lerdorf wrote:
- Remove register_globals completely
- Remove magic_quotes_*
- 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.
- 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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
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.
- Remove register_globals completely
+1
- Remove magic_quotes_*
+1
- 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.
- 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
- 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:
- Make identifiers case-sensitive
+1
- Radically change all the operator syntaxes. Oh wait, that's Perl
6.0, sorry.
George
- 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
- 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
I wrote up the following spec for this extension:
http://files.derickrethans.nl/filter_extension.htmlWhere'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?
Nah, we discussed this thing for a bit, but I didn't add that function
yet to this RFC.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
I wrote up the following spec for this extension:
http://files.derickrethans.nl/filter_extension.htmlWhere'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?Nah, we discussed this thing for a bit, but I didn't add that function
yet to this RFC.
Good. That function would be evil (imho). Given that you can't
access super-globals as variable-variables, I think that having to
really get at _RAW_GET[] will make it much more transparent when an
application is using unfiltered data.
George
Good. That function would be evil (imho). Given that you can't access
super-globals as variable-variables, I think that having to really get at
_RAW_GET[] will make it much more transparent when an application is using
unfiltered data.
But then everybody will just start using $_RAW_GET instead of $_GET.
What will that solve?
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
But then everybody will just start using $_RAW_GET instead of $_GET.
What will that solve?
This was one of my concerns.
$RAW* is easy to grep for, though.
Sure, it can still be abused, but it'll be a lot easier to see WHERE
it's being abused. Currently, a grep for $_GET will return a large
number of false positives when searching for XSS (because it's the most
legit way of finding data entry points).
S
Derick,
That would not be much different then someone doing
foreach (array_keys($_GET) $v) $_GET[$v] = get_raw(GET, $v);
If anything locating RAW super-global would be easier, making auditing
coding reliant on it a bit simpler.
IMHO.
Derick Rethans wrote:
Good. That function would be evil (imho). Given that you can't access
super-globals as variable-variables, I think that having to really get at
_RAW_GET[] will make it much more transparent when an application is using
unfiltered data.But then everybody will just start using $_RAW_GET instead of $_GET.
What will that solve?Derick
Good. That function would be evil (imho). Given that you can't
access
super-globals as variable-variables, I think that having to really
get at
_RAW_GET[] will make it much more transparent when an application
is using
unfiltered data.But then everybody will just start using $_RAW_GET instead of $_GET.
What will that solve?
No... reasonable people will use _GET. Applications that need to use
_RAW_GET will do so, and (due to the lack of variable variables
support for it) be easy to track down. With a function it's much
harder to track when you're getting the filtered attay or the raw array.
George
On Fri, 12 Aug 2005 20:19:04 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
- 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
It lools globally good for the principles. Details can be changed
during implementation/experimentations phases.
I only disagree with E_NOTICE. All these validations should be
silent. Derick, as far as I remember, you have some doubts about
that too. As you may noticed before, I have some problems with
noisy functions in general :)
Regards,
--Pierre
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
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
Best regards,
Marcus
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
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.
George mentioned this as a joke...
Derick
i'd suppose u guys going to deprecate+E_STRICT first, remove later
George Schlossnagle schrieb:
Radically change all the operator syntaxes.
http://www.gravitonic.com/software/php/patches/ze2_concat_obj_op.diff.gz
FYI: _ is validate char in variable/function name
("Hello! world"); // gettext
define('', 1);
echo _;
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:
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] = $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 for BC
- Radically change all the operator syntaxes. Oh wait, that's Perl
6.0, sorry.
In the same spirit, on my PHP 7.0 wishlist are Unicode operators. :)
-adam
--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!
+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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
Remove various function aliases
-Rasmus
Rasmus Lerdorf schrieb:
- Remove register_globals completely
+1
- Remove magic_quotes_*
+1
- 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
- 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
- Remove some stuff that has been marked deprecated since PHP 3/4
+1
- Make identifiers case-sensitive
+1
- 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
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
Maybe this is too far reaching but what about making function
parameter orders consistent? For example, make in_array() require
in_array(array haystack, mixed needle[...) just as most of the string
functions.
-D
This is a very good, point we really should drop support for things
like
gd1 (no reason anymore, latest versions (including bundled) have GIF
support). These only add a hundreds of ifdefs to the code or prevent
usage of new(er) functionality.IMHO we should see what is the lowest possible version of a lib
distributed by commonly used distro and upgrade our requirements to @
least that version.Ilia
Pierre-Alain Joye wrote:
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
--
Darrell Brogdon
darrell@brogdon.net
http://darrell.brogdon.net
Very good idea. We do bundle the thing? :)
--Jani
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
On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
sniper@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
On Sat, 13 Aug 2005 00:21:29 +0300 (EEST)
sniper@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
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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
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 WishlistSince 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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
Remove various function aliases
-Rasmus
Hi Davey Shafik!
On 08/12/05 20:56 you wrote:
As little as it means, +1
Same from here! :)
Cheers!
Toby
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579
a passion for php http://www.schlitt.info
Like to say "thank you"? - http://pear.php.net/wishlist.php/toby
- Remove register_globals completely
Amen! +1
- Remove magic_quotes_*
Hallelujiah! +1
- 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
- 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
- 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.
- 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:
- Make identifiers case-sensitive
Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
being (mostly) case-insensitive.
- 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.
- Make identifiers case-sensitive
Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
being (mostly) case-insensitive.
We can't make it optional... that would be just too much problems for
writing portable scripts.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello Derick,
Saturday, August 13, 2005, 2:17:52 PM, you wrote:
- Make identifiers case-sensitive
Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
being (mostly) case-insensitive.
We can't make it optional... that would be just too much problems for
writing portable scripts.
hu? How isn't always using the right casing un-portable if allowing
case-insensitivity also? You mean becuase one might use
function bullshit()...and
function Bullshit()...and
function bullShit()...?
If so, i guess you know how to write portable apps - test them with
everything supported - in this case with and w/o case-insensitivity.
Thus your argument is untrue. And the try of disproval above, look
at the used names.
Best regards,
Marcus
Hello internals,
Saturday, August 13, 2005, 2:58:26 PM, you wrote:
Hello Derick,
Saturday, August 13, 2005, 2:17:52 PM, you wrote:
- Make identifiers case-sensitive
Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
being (mostly) case-insensitive.
We can't make it optional... that would be just too much problems for
writing portable scripts.
hu? How isn't always using the right casing un-portable if allowing
case-insensitivity also? You mean becuase one might use
function bullshit()...and
function Bullshit()...and
function bullShit()...?
If so, i guess you know how to write portable apps - test them with
everything supported - in this case with and w/o case-insensitivity.
Thus your argument is untrue. And the try of disproval above, look
at the used names.
to prevent confusion with more readers - i am against an ini option here.
Either keep the way it is right now or make everything case sensitive.
And of course i like speed which is support for the latter to be clear.
Best regards,
Marcus
Marcus Boerger wrote:
to prevent confusion with more readers - i am against an ini option here.
Either keep the way it is right now or make everything case sensitive.
And of course i like speed which is support for the latter to be clear.
What about deprecating case-insensitive identifiers but keeping them
working. Wouldn't something like following work?
lookup case-sensitive identifier
if not found then
lookup case-insensitive identifier
if found then
raise notice/warning and continue as usual
else
fall down and catch fire
That way correct usage should be fast and incorrect usage work. And the
case-insensitive fallback could be removed in PHP7 :)
Ants Aasma
Hello Derick,
Saturday, August 13, 2005, 2:17:52 PM, you wrote:
- Make identifiers case-sensitive
Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
being (mostly) case-insensitive.We can't make it optional... that would be just too much problems for
writing portable scripts.hu? How isn't always using the right casing un-portable if allowing
case-insensitivity also? You mean becuase one might use
function bullshit()...and
function Bullshit()...and
function bullShit()...?
If so, i guess you know how to write portable apps - test them with
everything supported - in this case with and w/o case-insensitivity.
Yes, I know how to do that, but I'm not everybody. I already see people
doing:
function FooBar() {
}
fooBar();
or:
GetImageSize()
in their script. This will work fine if your ini setting says that it is
allowed, but as soon as you move it to a server where the setting is set
to off, your application stops working. So there is definitely an issue
here.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Sat, 13 Aug 2005 14:17:52 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
- Make identifiers case-sensitive
Or perhaps optionally case sensitive? I dunno, I've made my
peace with PHP being (mostly) case-insensitive.We can't make it optional... that would be just too much problems
for writing portable scripts.
The problem is not the portability but the internals, I think that
too much options make the whole thing way too complicated.
short version, do it or not, not optional :)
--Pierre
Rasmus Lerdorf wrote:
[lots of reasonable points]
What about moving some/many extensions from core to pecl?
Regards,
Mike
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
A reasonable goal would be to make sure that all our extensions are
full pecl citizens, so that intermediate fixes to any of these so
called "core" extensions could be released via PECL very easily.
One of the biggest gripes our SA's have is that if they forget to
enable a core PHP extension and later need to add it, there is no easy
way to pull it in, short of recompiling PHP again.
--Wez.
Rasmus Lerdorf wrote:
[lots of reasonable points]
What about moving some/many extensions from core to pecl?
Regards,
Mike
PS: This doesn't necessarily mean that they all need to be physically
unbundled from the main distro.
--Wez.
A reasonable goal would be to make sure that all our extensions are
full pecl citizens, so that intermediate fixes to any of these so
called "core" extensions could be released via PECL very easily.One of the biggest gripes our SA's have is that if they forget to
enable a core PHP extension and later need to add it, there is no easy
way to pull it in, short of recompiling PHP again.--Wez.
Rasmus Lerdorf wrote:
[lots of reasonable points]
What about moving some/many extensions from core to pecl?
Regards,
Mike
Wez Furlong 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
- 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
- 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. :)
Technically it's possible I guess. Just no time to do it :)
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
- 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. :)Technically it's possible I guess. Just no time to do it :)
I had this working with apc and apd. If any opcode cache goes into
the core, I'll happily work out interoperation with all the profilers.
George
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
- Remove register_globals completely
+1
- Remove magic_quotes_*
+1000
- 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:
- 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.
- Remove various function aliases
+1
-Rasmus
Might I add a few requests:
-
Much improved __toString behavior (I doubt I'd need to clarify that)
-
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. -
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. -
I hate to bring this up, don't shoot me for this, but ... multiple
inheritance? ;) -
A built-in code optimizer. Why should something like Zend optimizer be
installed afterwards, if everybody can use increased performance? -
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. -
Remove $HTTP_* (altho you may have included that when you thought of #6)
and register_long_arrays. -
Support for <?php="foo" ?>
-
A reliable non-bankers-round function
-
The ability to use an array() of constants in a define.
Maybe I'll think of more later ;)
Ron
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
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
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.
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
Ron Korving wrote:
- 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
Ron Korving wrote:
- Support for <?php="foo" ?>
that reminds me:
set short_open_tags to off in any sample php.ini we ship.
regards,
Lukas
Ron Korving wrote:
- Support for <?php="foo" ?>
that reminds me:
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me:
17. Nuke every "alternative" open tag and only have <?php
--Jani
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me: 17. Nuke every "alternative" open tag and only have <?php
Agreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss <script language="php"> into the
conversation and get nothing but doubtful stares. Is this used anywhere
except academic examples?
-Sara
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me: 17. Nuke every "alternative" open tag and only have <?phpAgreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss <script language="php"> into the
conversation and get nothing but doubtful stares. Is this used anywhere
except academic examples?
I'd say "no", but I think some Zend boys use it since Stas (or someone else)
raised a hell after some changes in this stuff not long ago.. ;)
--Jani
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me: 17. Nuke every "alternative" open tag and only have <?phpAgreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss <script language="php"> into the
conversation and get nothing but doubtful stares. Is this used anywhere
except academic examples?
No idea, but it should go.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
- Remove register_globals completely
+1 (then we can cleanup the mess in ext/session too :)
- Remove magic_quotes_*
+1 (definately, finally, at last! The filter stuff obsoletes those anyway?)
- 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)
- 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)
- Remove safe_mode and focus on open_basedir
+1
- 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:
- 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..
- 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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
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
+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
Lukas Smith wrote:
Speaking of *kit .. how about sandboxing or some sort of taint model.
i'd beg for that.
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.
- Remove register_globals completely
+1
- Remove magic_quotes_*
+1
- 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
- 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
- Remove safe_mode and focus on open_basedir
+1
- 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:
- Make identifiers case-sensitive
+10
- 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?
-
__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. -
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.) -
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). -
{} vs [] cleanup
12a. using {} for strings could also bring us substr() functionality to {}.
-
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. -
i read drop gd1, nice one
-
i think of splitting dba, making ini-file into dba core and putting all
but dba core into pecl (further plans for ini-file). -
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 wrote:
- 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
Hello Lukas,
Saturday, August 13, 2005, 1:34:35 AM, you wrote:
Marcus Boerger wrote:
- 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
Marcus Boerger wrote:
- __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?
- 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.
- {} 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
- 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
- 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
- {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny unresolved issues.
-Andrei
I thought we've discussed making one access code-units and the other
code-points?
Ilia
Andrei Zmievski wrote:
- {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny unresolved issues.
-Andrei
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
I thought we've discussed making one access code-units and the other
code-points?Ilia
Andrei Zmievski wrote:
- {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny unresolved issues.
-Andrei
What's bad about using [] for strings? I think people who come from a
C-background (like myself) really like that syntax. I'd prefer it to stay
the way it is.
Ron
"Andrei Zmievski" andrei@gravitonic.com wrote in message
news:73D65ACE-D442-41FF-A35C-42D92F7B7A75@gravitonic.com...
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
I thought we've discussed making one access code-units and the other
code-points?Ilia
Andrei Zmievski wrote:
- {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny unresolved issues.
-Andrei
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,
+100
with some sort of BC switch.
-Inf
We're talking about cleaning up legacy stuff, not creating new, aren't we? :)
And iirc, using [] for strings has been "deprecated" for ages now.
--Jani
Hello Jani,
Sunday, August 14, 2005, 2:37:36 AM, you wrote:
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,
+100
with some sort of BC switch.
-Inf
We're talking about cleaning up legacy stuff, not creating new, aren't we? :) And iirc, using [] for strings has been "deprecated" for ages now.
agreed totally, thanks and amen (hopefully)
Best regards,
Marcus
-Inf We're talking about cleaning up legacy stuff, not creatingnew, aren't we? :)
And iirc, using [] for strings has been "deprecated" for ages
now.
Not really. [] and {} compile to exactly the same thing, actually.
-Andrei
-Inf We're talking about cleaning up legacy stuff, not creating new, aren'twe? :)
And iirc, using [] for strings has been "deprecated" for ages now.Not really. [] and {} compile to exactly the same thing, actually.
Might be true, but the manual lists this for years already:
http://www.php.net/manual/en/language.types.string.php#language.types.string.parsing.complex
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hello Derick,
Sunday, August 14, 2005, 12:47:46 PM, you wrote:
-Inf We're talking about cleaning up legacy stuff, not creating new, aren'twe? :)
And iirc, using [] for strings has been "deprecated" for ages now.Not really. [] and {} compile to exactly the same thing, actually.
Might be true, but the manual lists this for years already:
http://www.php.net/manual/en/language.types.string.php#language.types.string.parsing.complex
So if we stick to the docs then [] == arrays, {} == strings and we're happy.
Best regards,
Marcus
Then we should fix one or the other.
-Andrei
Might be true, but the manual lists this for years already:
http://www.php.net/manual/en/
language.types.string.php#language.types.string.parsing.complexDerick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
I thought we've discussed making one access code-units and the other
code-points?
And the reason why I want this is speed. [1231231] vs. {1231231}, having
the first one access codeunits would be quite a lot faster as not the
whole string has to be scanned for every usage of {}.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
So, you'd rather have PHP users gain some speed at the expense of
having to check for surrogates everywhere?
-Andrei
I thought we've discussed making one access code-units and the other
code-points?And the reason why I want this is speed. [1231231] vs. {1231231},
having
the first one access codeunits would be quite a lot faster as not the
whole string has to be scanned for every usage of {}.Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
So, you'd rather have PHP users gain some speed at the expense of having to
check for surrogates everywhere?
In quite some cases for me i'm sure there are no surrogates in the text
I'm parsing. Having to deal with rescanning the string for every
access to a character is not really wanted.
Derick
Then why don't we put our collective brains together and think of a
solution for this that does not involve hacks?
-Andrei
In quite some cases for me i'm sure there are no surrogates in the
text
I'm parsing. Having to deal with rescanning the string for every
access to a character is not really wanted.Derick
Back in the early days of the extension, i had a request global
ICUG(codepoint_semantics) which controlled this. Setting this to false would
revert to code-unit indexing (which ICU does internally).
clayton
"Andrei Zmievski" andrei@gravitonic.com wrote in message
news:133A42C8-184B-49F3-8EEA-3B595B4BD062@gravitonic.com...
Then why don't we put our collective brains together and think of a
solution for this that does not involve hacks?-Andrei
In quite some cases for me i'm sure there are no surrogates in the text
I'm parsing. Having to deal with rescanning the string for every
access to a character is not really wanted.Derick
And this was controlled how and from where?
-Andrei
On Aug 14, 2005, at 12:29 PM, cshmoove@bellsouth.net
cshmoove@bellsouth.net wrote:
Back in the early days of the extension, i had a request global
ICUG(codepoint_semantics) which controlled this. Setting this to
false would
revert to code-unit indexing (which ICU does internally).clayton
"Andrei Zmievski" andrei@gravitonic.com wrote in message
news:133A42C8-184B-49F3-8EEA-3B595B4BD062@gravitonic.com...Then why don't we put our collective brains together and think of a
solution for this that does not involve hacks?-Andrei
In quite some cases for me i'm sure there are no surrogates in
the text
I'm parsing. Having to deal with rescanning the string for every
access to a character is not really wanted.Derick
Andrei,
it was controlled by an ini setting. there are certain APIs that take or
return offsets, so translation
was done in those instances depending on the setting. Here's an example
(it's not currently implemented
this way, though..) since my concern was only the extension, i didnt touch
the engine itself..
pardon the formatting....
<code> /* {{{ proto long BreakIterator::next([long offset]) */ static ZEND_BEGIN_ARG_INFO_EX(arginfo_breakiterator_next, 0, 0, 0) ZEND_ARG_INFO(0, offset) ZEND_END_ARG_INFO();BREAKITERATOR_METHOD(next)
{
php_breakiterator_obj *obj =
(php_breakiterator_object *)zend_object_store_get_object(getThis()
TSRMLS_CC);
BreakIterator *iter = (BreakIterator *)obj->ptr;
UnicodeString *text = obj->text;
long offset, result;
if (0 == ZEND_NUM_ARGS()) {
offset = (long)iter->next();
} else {
long start = 0;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l",
&start)) {
return;
}
if (ICUG(codepoint_semantics)) {
FROM_CODEPOINT_INDEX(text->getBuffer(), text->length(), start, offset);
offset = (long)iter->next(offset);
} else {
offset = (long)iter->next(start);
}
}
if (ICUG(codepoint_semantics)) {
long result;
TO_CODEPOINT_INDEX(text->getBuffer(), text->length(), offset, result);
RETURN_LONG(result);
} else {
RETURN_LONG(offset);
}
}
/* }}} */
clayton
"Andrei Zmievski" andrei@gravitonic.com wrote in message
news:F269F06B-C34A-4BE0-A486-9C0AAC9CA2DF@gravitonic.com...
And this was controlled how and from where?
-Andrei
On Aug 14, 2005, at 12:29 PM, cshmoove@bellsouth.net
cshmoove@bellsouth.net wrote:Back in the early days of the extension, i had a request global
ICUG(codepoint_semantics) which controlled this. Setting this to false
would
revert to code-unit indexing (which ICU does internally).clayton
"Andrei Zmievski" andrei@gravitonic.com wrote in message
news:133A42C8-184B-49F3-8EEA-3B595B4BD062@gravitonic.com...Then why don't we put our collective brains together and think of a
solution for this that does not involve hacks?-Andrei
In quite some cases for me i'm sure there are no surrogates in the
text
I'm parsing. Having to deal with rescanning the string for every
access to a character is not really wanted.Derick
Andrei,
it was controlled by an ini setting. there are certain APIs that take or
return offsets, so translation
If it's an INI setting then it hurts portability. I definitely do not
want that to happen as this would revert the whole shebang into
codeunit mode.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
agreed, but the point was more about the implementation than how the mode is
set. a function call is good enough for me.
clayton
"Derick Rethans" derick@php.net wrote in message
news:Pine.LNX.4.62.0508150913430.2742@localhost...
Andrei,
it was controlled by an ini setting. there are certain APIs that take
or
return offsets, so translationIf it's an INI setting then it hurts portability. I definitely do not
want that to happen as this would revert the whole shebang into
codeunit mode.Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Marcus Boerger wrote:
- __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.
+1. Either that or just drop __toString altogether. Right now it's
about worse than useless, as it's hard to understand exactly when it
will and won't be called.
- 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.
A big +1 for namespaces, -1 for namespacing existing internal
functions (or somehow importing them by default so that they can be
referenced by their current name.
- 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
-1
George
+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
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
Remove various function aliases
+1 to all things here.
- Shared memory storage for variables with transparent access.
(superglobal array?)
--
Ondrej Ivanic
(ondrej@kmit.sk)
- Shared memory storage for variables with transparent access.
(superglobal array?)
-1. This is hard to make consistent across all platforms, and will
break instantly when you go past 1 machine, making it confusing and
of marginal usage.
George
- Shared memory storage for variables with transparent access. (superglobal
array?)-1. This is hard to make consistent across all platforms, and will break
instantly when you go past 1 machine, making it confusing and of marginal
usage.
Maybe this could be something that ext/session could provide.
I sure can find some uses for a 'global session'.
--Jani
- Shared memory storage for variables with transparent access.
(superglobal array?)-1. This is hard to make consistent across all platforms, and
will break instantly when you go past 1 machine, making it
confusing and of marginal usage.Maybe this could be something that ext/session could provide. I sure can find some uses for a 'global session'.
That seems like a reasonable to go. I question it's utility a bit -
how often is this really useful? For large objects (like a real
cache), this isn't the best place to store it, for most resources it
won't work at all. So what's a typical use case for this?
George
Maybe this could be something that ext/session could provide. I sure can find some uses for a 'global session'.That seems like a reasonable to go. I question it's utility a bit - how often
is this really useful? For large objects (like a real cache), this isn't the
best place to store it, for most resources it won't work at all. So what's a
typical use case for this?
I wasn't even dreaming of using it for storing stuff like objects in it.
As a real world example, I'd use something like that for "locking" stuff
in the admin interface, e.g. when someone opens an item for editing,
it's locked for all other moderators/administrators/etc...
Of course I can accomplish that by a separate table in the database,
but I'd like to avoid any unnecessary writes to DB whenever possible. :)
Anyone have any other solutions to this (I'd guess quite common problem)
I'm open for suggestions. :)
Some other uses for a "global session" might be forums and their
'show online users' feature.
--Jani
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Ilia
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a 'global session' that is available with multiple
front-end servers..ie. using DB as session storage.
--Jani
Jani Taskinen wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage.
I am confused. What are you proposing here? That we write a
multi-server memory-based datastore? That's a project in itself and
quite beyond the scope of PHP. It would seem to me like a replicated
database setup with decent query caching solves this problem nicely.
-Rasmus
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations.
I need such a 'global session' that is available with multiple
front-end servers..ie. using DB as session storage.I am confused. What are you proposing here? That we write a
multi-server memory-based datastore? That's a project in itself and
quite beyond the scope of PHP. It would seem to me like a replicated
database setup with decent query caching solves this problem nicely.-Rasmus
How about an implementation with multiple possible backends ala
session.save_handler?
It could use "files" or "apc" by default, or optionally use something
like "mm", "msession" or "mysql" depending on the user's needs.
Marc
Marc Richards wrote:
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations.
I need such a 'global session' that is available with multiple
front-end servers..ie. using DB as session storage.I am confused. What are you proposing here? That we write a
multi-server memory-based datastore? That's a project in itself and
quite beyond the scope of PHP. It would seem to me like a replicated
database setup with decent query caching solves this problem nicely.-Rasmus
How about an implementation with multiple possible backends ala
session.save_handler?It could use "files" or "apc" by default, or optionally use something
like "mm", "msession" or "mysql" depending on the user's needs.Marc
Oops. Hit send a little early.
Just to clarify, the value of adding this extra layer of complexity
would be that developers could write apps that persitently store and
retrieve data at an application level without worrying about
portability. It would then be up to the server admin to choose the
appropriate backend based on their own requirements such as speed,
platform, security, or multi-server configuration.
I would envision it working in a manner very similar to how sessions
work now, including the use of a user-configurable an APPLICATION_ID to
prevent colisions.
Marc
Jani Taskinen wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage.
True enough, but surely good enough for a number of users to use. The
fact that you need central session storage because (I'm guessing here)
your frontends are behind a handful of load balancers is something
which, well, lets face it - is pretty rare as far as the average users
experiance goes.
Just my 2c.
Jani Taskinen wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage.
It's a feature, not a bug :)
At this moment I playing with daemon which receive messages from network
(broadcast/multicast) and store it to shmem segment. PHP scripts only
reads this data.
--
Ondrej Ivanic
(ondrej@kmit.sk)
If apc comes bundled then it includes apc_store() and apc_fetch()
this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage.
ext/session has the framework for doing this. I concur with your
original idea of augmenting it to provide those services. Perhaps a
new autoglobal $_GLOBAL_SESSION[]. Thoughts?
George
If apc comes bundled then it includes apc_store() and apc_fetch()
this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage.ext/session has the framework for doing this. I concur with your
original idea of augmenting it to provide those services. Perhaps a
new autoglobal $_GLOBAL_SESSION[]. Thoughts?George
IIRC, ages ago when I used ASP pages there as an "Application" object
which was basically identical to this concept. I seem to recall using
it for configuration kinds of thing (db connections, etc).
I have resorted to caching for similar needs in PHP, I think
$_GLOBAL_SESSION would be welcome addition, perhaps even allowing for
customs session handlers similar to the $_SESSION now for
multi-processor environments and other unique setup problems.
Regards,
Jason
http://blog.casey-sweat.us/
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage.ext/session has the framework for doing this. I concur with your original
idea of augmenting it to provide those services. Perhaps a new autoglobal
$_GLOBAL_SESSION[]. Thoughts?
<?php
<the usual pre-session_start() things here..>
session_set_application_id('someid');
`session_start()`;
$_SESSION['foobar'] = 'foo';
$_GLOBAL['someid'] = 'bar';
etc.
?>
Thanks to Marc for mentioning the application id. :)
It should propably behave so that if the application id
is not set, then we won't init the $_GLOBAL at all.
--Jani
>
>
>
>>
>>
>>
>>
>>>
>>>
>>>> If apc comes bundled then it includes apc_store() and apc_fetch
>>>> () this
>>>> is pretty much $_MEMORY with a few tweaks.
>>>>
>>> Yes, but that is restricted to one server installations.
>>> I need such a 'global session' that is available with multiple
>>> front-end servers..ie. using DB as session storage.
>>>
>>
>> ext/session has the framework for doing this. I concur with your
>> original idea of augmenting it to provide those services. Perhaps
>> a new autoglobal $_GLOBAL_SESSION[]. Thoughts?
>>
>
> <?php
>
>
>
> session_set_application_id('someid');
Why shouldn't this be implicit (and bound to a userid under safe
mode). i.e. what's the point of having an application id?
George
George Schlossnagle wrote:
>
>
>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>> If apc comes bundled then it includes apc_store() and apc_fetch ()
>>>>> this
>>>>> is pretty much $_MEMORY with a few tweaks.
>>>>>
>>>> Yes, but that is restricted to one server installations.
>>>> I need such a 'global session' that is available with multiple
>>>> front-end servers..ie. using DB as session storage.
>>>>
>>>
>>> ext/session has the framework for doing this. I concur with your
>>> original idea of augmenting it to provide those services. Perhaps a
>>> new autoglobal $_GLOBAL_SESSION[]. Thoughts?
>>>
>>
>> <?php
>>
>>
>>
>> session_set_application_id('someid');
>
>
> what's the point of having an application id?
To prevent PHPBB from accidentally overwriting Phorum when both of them
try to update $_GLOBAL_SESSION['counter']. Basically to enforce
application level scoping...which is part of the reason I think
$_APPLICATION is a better name.
Marc
Rasmus Lerdorf wrote:
- 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
-
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"); -
Allow dangling commas in function calls, handy with varargs and 9:
foo(1, 2, 3,);
Minor:
- HTTP response splitting attack protection: Replace \r and \n with
space inheader();
Information and patches implementing this can be found at
http://cschneid.com/php/
- Chris
Hello,
Minor:
- HTTP response splitting attack protection: Replace \r and \n with
space inheader();Information and patches implementing this can be found at
http://cschneid.com/php/
Your patches are problematic when a proxy kills overlong header lines
that were not split up by the client onto multiple lines. Therefore \r\n
followed by whitespace should not be replaced with spaces..Otherwise
this could destroy legit functionality.
A similiar patch for this is in Hardening-Patch above 0.3.x
Ohh and btw: this is not a minor point, because it completely kills the
whole attack class for PHP applications with 3-5 lines of code.
Stefan Esser
--
Stefan Esser sesser@php.net
Hardened-PHP Project http://www.hardened-php.net/
GPG-Key gpg --keyserver pgp.mit.edu --recv-key 0x15ABDA78
Key fingerprint 7806 58C8 CFA8 CE4A 1C2C 57DD 4AE1 795E 15AB DA78
How about we do this:
Add a 3rd optional param to header(), if it is unset we remove
everything from a header that contains \r\n or \n after those chars.
However if the developer feels the need to send multiple headers or what
not they can pass 3rd arg as TRUE and "restore" the functionality.
Ilia
Stefan Esser wrote:
Hello,
Minor:
- HTTP response splitting attack protection: Replace \r and \n with
space inheader();Information and patches implementing this can be found at
http://cschneid.com/php/Your patches are problematic when a proxy kills overlong header lines
that were not split up by the client onto multiple lines. Therefore \r\n
followed by whitespace should not be replaced with spaces..Otherwise
this could destroy legit functionality.A similiar patch for this is in Hardening-Patch above 0.3.x
Ohh and btw: this is not a minor point, because it completely kills the
whole attack class for PHP applications with 3-5 lines of code.Stefan Esser
Hello Ilia,
if you look at the implementation of header() you will realise that
sending multiple headers is actually already abusing how it was designed
to work. Because the internal checks for double headers etc. do not work
at all when you send multiple headers.
Stefan
I am a bit reluctant to remove the old "functionality" outright, hence
the optional flag. Either way it seems better then what we've got right now.
Ilia
Stefan Esser wrote:
Hello Ilia,
if you look at the implementation of
header()you will realise that
sending multiple headers is actually already abusing how it was designed
to work. Because the internal checks for double headers etc. do not work
at all when you send multiple headers.Stefan
Christian Schneider wrote:
Rasmus Lerdorf wrote:
- 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
- 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");
s
- 0.5
- Allow dangling commas in function calls, handy with varargs and 9:
foo(1, 2, 3,);
-1 . function calls
Minor:
- HTTP response splitting attack protection: Replace \r and \n with
space inheader();Information and patches implementing this can be found at
http://cschneid.com/php/
- Chris
Andrey
- Christian Schneider cschneid@cschneid.com :
- 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");
+1 -- this is one of the biggest things I miss coming from perl to PHP.
--
Matthew Weier O'Phinney
Zend Certified Engineer
http://weierophinney.net/matthew/
Perhaps the named parameters could even be constant-like?
How would this syntax be?
foo(id => 42, name => "foo");
Ron
"Matthew Weier O'Phinney" mweierophinney@gmail.com wrote in message
news:slrndfs5ef.rck.mweierophinney@ubergeek.garden.org...
- Christian Schneider cschneid@cschneid.com :
- 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");+1 -- this is one of the biggest things I miss coming from perl to PHP.
--
Matthew Weier O'Phinney
Zend Certified Engineer
http://weierophinney.net/matthew/
- Christian Schneider cschneid@cschneid.com :
- 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");+1 -- this is one of the biggest things I miss coming from perl to
PHP.
Huh? Perl doesn't have true support for this anyway, just a simpler
syntax for hashrefs. If you want Perlish named params this is 100%
identical to doing
foo(array('id' => 42, 'name' => 'foo'));
George
George Schlossnagle wrote:
- Christian Schneider cschneid@cschneid.com :
- 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");+1 -- this is one of the biggest things I miss coming from perl to PHP.
Huh? Perl doesn't have true support for this anyway, just a simpler
syntax for hashrefs. If you want Perlish named params this is 100%
identical to doingfoo(array('id' => 42, 'name' => 'foo'));
George
Well, this idea I think comes from Python. Last time I checked they had these
and as far as I remember this have been brought 2 times. The first time before
5.0 and has been rescheduled for 6.0 :)
Andrey
George Schlossnagle wrote:
- Christian Schneider cschneid@cschneid.com :
- 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");+1 -- this is one of the biggest things I miss coming from perl
to PHP.Huh? Perl doesn't have true support for this anyway, just a
simpler syntax for hashrefs. If you want Perlish named params
this is 100% identical to doing
foo(array('id' => 42, 'name' => 'foo'));
GeorgeWell, this idea I think comes from Python. Last time I checked they
had these
and as far as I remember this have been brought 2 times. The first
time before
5.0 and has been rescheduled for 6.0 :)
:)
I'm not against named parameters. Python's support for them is nice
as well. But Perl doesn't support named parameters any different
than can be done currently in PHP.
George
George Schlossnagle wrote:
George Schlossnagle wrote:
- Christian Schneider cschneid@cschneid.com :
- 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");+1 -- this is one of the biggest things I miss coming from perl to
PHP.Huh? Perl doesn't have true support for this anyway, just a
simpler syntax for hashrefs. If you want Perlish named params this
is 100% identical to doing
foo(array('id' => 42, 'name' => 'foo'));
GeorgeWell, this idea I think comes from Python. Last time I checked they
had these
and as far as I remember this have been brought 2 times. The first
time before
5.0 and has been rescheduled for 6.0 :):)
I'm not against named parameters. Python's support for them is nice as
well. But Perl doesn't support named parameters any different than can
be done currently in PHP.George
I could be wrong, but I think you were the one who first wanted named parameters
that long time ago :)
Andrey
George Schlossnagle wrote:
George Schlossnagle wrote:
- Christian Schneider cschneid@cschneid.com :
- 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");+1 -- this is one of the biggest things I miss coming from
perl to PHP.Huh? Perl doesn't have true support for this anyway, just a
simpler syntax for hashrefs. If you want Perlish named params
this is 100% identical to doing
foo(array('id' => 42, 'name' => 'foo'));
GeorgeWell, this idea I think comes from Python. Last time I checked
they had these
and as far as I remember this have been brought 2 times. The
first time before
5.0 and has been rescheduled for 6.0 :):)
I'm not against named parameters. Python's support for them is
nice as well. But Perl doesn't support named parameters any
different than can be done currently in PHP.
GeorgeI could be wrong, but I think you were the one who first wanted
named parameters
that long time ago :)
Possibly, which would fall inline with not being against them now. :)
I like them in Python. The ones in Perl are a hack, though, with
limitations on how they can be positioned, lack of prototyping and
default values, etc. The Python ones are much more flexible, imho.
The only difference between Perl's support for named params and PHP's
current support is that in Perl:
foo( a => 1, b => 2) is the same as foo((a => 1, b => 2)), i.e. that
you have in Perl:
(a => 1, b => 2)
whereas in PHP we have
array('a' => 1, 'b' => 2);
Andrey
George Schlossnagle
-- Vice President of Engineering
-- OmniTI Computer Consulting
-- http://www.omniti.com
I would like to see the Type Hinting expanded in PHP 6. In 5 now you can do
class Test {
public function testDatabase( Database $db ) {
}
}
what if i wanted to make sure it was a String, Integer, Boolean, Float,
etc.. i would like to see that added to the type hinting ;)
--
Joseph Crawford Jr.
Codebowl Solutions, Inc.
1-802-671-2021
codebowl@gmail.com
Talking about type hinting. It would be nice to be able to declare
variables as a certain type once and for all (like c, although
optional). I don't if this has been discussed and dismissed before,
and if that is the case, please don't kill me. You're just
brainstorming anyway, right? :)
Emil
i agree with the last post, it would be nice for PHP to be a weakly typed
language but allow for the user to program strongly typed if they want to
such as the above suggestion of having the option to declare the type for a
variable.
--
Joseph Crawford Jr.
Codebowl Solutions, Inc.
1-802-671-2021
codebowl@gmail.com
Hello Emil,
Sunday, August 14, 2005, 12:49:46 AM, you wrote:
Talking about type hinting. It would be nice to be able to declare
variables as a certain type once and for all (like c, although
optional). I don't if this has been discussed and dismissed before,
and if that is the case, please don't kill me. You're just
brainstorming anyway, right? :)
Brainstorming, yes. Typehinting for class properties maybe. For normal
variables it would be to slow. And we want some speed back do we?
Best regards,
Marcus
Hello Joseph,
Sunday, August 14, 2005, 12:31:42 AM, you wrote:
I would like to see the Type Hinting expanded in PHP 6. In 5 now you can do
class Test {
public function testDatabase( Database $db ) {
}
}
what if i wanted to make sure it was a String, Integer, Boolean, Float,
etc.. i would like to see that added to the type hinting ;)
we often enough decided against that (for the most we don't want to be
another language like java).
Best regards,
Marcus
what if i wanted to make sure it was a String, Integer, Boolean, Float,
etc.. i would like to see that added to the type hinting ;)
This is not going to happen. We've discussed this plenty of times
before.
Derick
George Schlossnagle wrote:
Huh? Perl doesn't have true support for this anyway, just a simpler
syntax for hashrefs. If you want Perlish named params this is 100%
identical to doing
foo(array('id' => 42, 'name' => 'foo'));
If you are using this a lot then syntactic sugar does make a difference
IMHO. That's why we decided to use a patch to allow foo('id' => 42,
'name' => "foo");
I agree that a fancier way would be to have something like
function foo($id = 42) { ... }
...
foo(id: 64738, name: "foo");
and then access them through $_PARAM['id'] (or $id because the function
definition declares $id) and $PARAM['name'] respectively. What I don't
like about Python at all is that AFAIK you can't call a method with
parameters not declared in the function definition. That's a very handy
feature for things like DB actions or HTML generation.
Missing from the fancier version: Parameter names which aren't valid
identifiers and preparing an array with values before calling a
function. The first is a more hypothetical limitation as
fields/attributes are normally not containing non-identifier characters
but the second is a bit more practical:
$record->insert('id' => 42, 'name' => "foo");
works just as well as
$tags = array('id' => 42, 'name' => "foo");
... # Add more key/values to $tags
$record->insert($tags);
without requiring insert() to distinguish between the two. If someone
can come up with an elegant way to populate $_PARAM on a function call
then both these limitations would be gone.
That's it about named parameters from my side for now,
- Chris
Christian Schneider wrote:
What I don't like about Python at all is that AFAIK you can't call a
method with parameters not declared in the function definition.
Oops, Python does allow this with a *parameter or **parameter. Missed
that part when reading the specs :-)
- Chris
"Christian Schneider" cschneid@cschneid.com wrote in message
news:42FE85AA.6020309@cschneid.com...
foo(id: 64738, name: "foo");
Oh, I love that syntax ;)
Ron
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:
Remove register_globals completely
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 :-)
- 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()) {
.. }" ).
- 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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
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
Aaron Wormus wrote:
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
It's very good idea ;) 6.0 is a major release, so it can break many
things, and with mod_php6 it can not worring about BC at all. I'm only
php user, not developer, but +1 from me.
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.
Remove register_globals completely
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.
- 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.
- 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.
- Remove safe_mode and focus on open_basedir
Sounds good.
- 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:
Make identifiers case-sensitive
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
Hi,
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.
I couldn't agree more.
Remove register_globals completely
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.
+1000 for not removing the register_globals.
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.
I sure hope others come to support your way of thinking. Sometimes
the purist way of thinking can cause more problems than good.
Zeev Suraski wrote:
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 agree that breaking BC is not a binary thing. I also agree that not
being academically pure has not prevent PHP from succeeding on quite a
large scale. However I think stuff like renaming functions and dropping
aliases can be easily countered by a BC lib like PEAR::PHP_Compat
(http://pear.php.net/package/PHP_Compat/). There is even a package in
PEAR that will determine the necessary includes you will need to make
based on your code and your PHP version
(http://pear.php.net/package/PHP_CompatInfo/).
Finally to fix stuff like parameter order we also have a tool readily
available (with a few minor tweaks to also cover internal functions)
which is called runkit (http://pecl.php.net/package/runkit).
Beyond that runkit also gives us sandboxing, which in absence of a
proper taint model is a huge step forward in handling data which may
come from all sort of distributed sources in larger projects.
As for removing register globals, a simple auto prepend will get you
register globals back, same goes for magic quotes. But moving this stuff
into userland will force people to take another hard look at their code.
So I think we have all the tools available to make PHP alot cleaner
without forcing people to rewrite their code. Since while our mess has
not hurt us, I am sure it has not helped us either.
regards,
Lukas
As for removing register globals, a simple auto prepend will get
you register globals back, same goes for magic quotes. But moving
this stuff into userland will force people to take another hard
look at their code.
Also a good thing for PHP_Compat.
Hello,
PHP 5 was an evolution of php4, adding good OO things and some new
extensions.
PHP 5.1 is going a bit further and make the new engine more
efficient.
Both keep old and annoyed things we had in php4.
PHP 6.0 is not going to be realease in the next months or maybe
even not this year.
PHP5 adoption is still anedoctic regarding php4 usages. So let say
people will have a lot of time to changes their codes and test it.
Or are you considering that having everything we had since php4
until the end of the days?
Regards,
--Pierre
Just my 2 cents :
-
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 -
make standarts for function's names.
For example php hasstr_replace()andstrpos(). 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. -
+1 namespaces
-
disable @ via settings
-
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.
Remove register_globals completely
Remove magic_quotes_*
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.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.Remove safe_mode and focus on open_basedir
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:
Make identifiers case-sensitive
Remove various function aliases
-Rasmus
- 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
- Remove register_globals completely
+1
- Remove magic_quotes_*
+100 (any "magic" is bad in the long run, see Perl)
- 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
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.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 tocreate_function().
--
Mikko
Hello Mikko,
Monday, August 22, 2005, 4:09:31 PM, you wrote:
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
- Remove register_globals completely
+1
- Remove magic_quotes_*
+100 (any "magic" is bad in the long run, see Perl)
- 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
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.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()orstrstr()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.
Read the docs and look for the upcoming input filtering.
- 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[]".
You can always grep the names, you can always access the raw data and well
early declining would require some more interaction with the sapi. So you'd
first need to contact the sapi wroters or find out whetehr that is possible
at all. The we'd need to find out how to handle that. In theory you have now
two threads, hmmm.
- 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.
At least apache should be able to write microseconds, on windows system sthe
problem would be the resolution of the internal time which is ~10ms. And an
E_PARSE will never be catchable by a PHP script.
- Anonymous functions. The real stuff, not just some odd string
passed tocreate_function().
There were some others already asking for this, maybe we should at least
give it a thought if it is doable at all, anybody?
Best regards,
Marcus
MB>>> * Anonymous functions. The real stuff, not just some odd string
MB>>> passed to create_function().
MB>>
MB>>There were some others already asking for this, maybe we should at least
MB>>give it a thought if it is doable at all, anybody?
Just out of curiosity, what's bad in create_function and how "real" ones
should be different?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
i think that create_function() does an eval() at runtime, which is more
expensive. anonymous functions would be handled in the compiler.
l0t3k
"Stanislav Malyshev" stas@zend.com wrote in message
news:Pine.LNX.4.62.0508222107200.13397@shire.zend.office...
Just out of curiosity, what's bad in create_function and how "real" ones
should be different?Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
l>>i think that create_function() does an eval() at runtime, which is more
l>>expensive. anonymous functions would be handled in the compiler.
Well, since function code is compiled once anyway, it shouldn't matter
much when it is compiled - before first opcode was executed or after that.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
i think that create_function() does an eval() at runtime, which is more
expensive. anonymous functions would be handled in the compiler.
l0t3k
"Stanislav Malyshev" stas@zend.com wrote in message
news:Pine.LNX.4.62.0508222107200.13397@shire.zend.office...
Just out of curiosity, what's bad in create_function and how "real" ones
should be different?Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
MB>>> * Anonymous functions. The real stuff, not just some odd string
MB>>> passed tocreate_function().
MB>>
MB>>There were some others already asking for this, maybe we should
at least
MB>>give it a thought if it is doable at all, anybody?Just out of curiosity, what's bad in create_function and how "real"
ones
should be different?
Two major differences as I see it:
-
syntactical: the amount of escaping/funkyjunk you need to do to
have anonymous functions look like regular functions in their
declaration is huge (yes, you can use heredocs, but they have their
(big if you run up against them) limitations as well). -
no garbage collection on them (so in something like perl, when you
anonymous sub goes out of scope, it's cleaned up). -
runtime vs. compiletime definition
For me 3 is good the way it is (the whole point of anon. functions
(for me) is to allow me to easily vary their definition at runtime).
2 I can see being a pain, but I don't consider it critical.
1 keeps me from using create_function - the required code is to
obtuse to use in most cases - I really would like to be able to do:
$max = function ($a, $b) {
return $a < $b?$b:$a;
}
(for why heredocs suck here, consider the case where I want to use
constants in the definition).
George
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115--
George Schlossnagle
-- Vice President of Engineering
-- OmniTI Computer Consulting
-- http://www.omniti.com
GS>>1) syntactical: the amount of escaping/funkyjunk you need to do to
GS>>have anonymous functions look like regular functions in their
GS>>declaration is huge (yes, you can use heredocs, but they have their
GS>>(big if you run up against them) limitations as well).
Well, this is right and valid, but if you use advanced stuff like closures
you may expect you code look "advanced" :)
GS>>2) no garbage collection on them (so in something like perl, when you
GS>>anonymous sub goes out of scope, it's cleaned up).
This is a valid concern, though I don't see how to fix it without creating
a new type, and creating anew type just for that seems a bit of overkill
to me.
GS>>3) runtime vs. compiletime definition
GS>>
GS>>For me 3 is good the way it is (the whole point of anon. functions (for me)
GS>>is to allow me to easily vary their definition at runtime).
This one I miss. Like, why should it matter when you compile it?
Compilation time is still the same. Even more, in runtime you don't spend
time compiling it unless it's really needed.
GS>>$max = function ($a, $b) {
GS>> return $a < $b?$b:$a;
GS>>}
$max = create_function('$a,$b', 'return $a < $b?$b:$a;');
Is it that different?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
MB>>> * Anonymous functions. The real stuff, not just some odd string
MB>>> passed tocreate_function().
MB>>
MB>>There were some others already asking for this, maybe we should at least
MB>>give it a thought if it is doable at all, anybody?Just out of curiosity, what's bad in create_function and how "real" ones
should be different?
"Real" anonymous functions (as in, closures) should be able to capture
variables from its lexical environment, e.g.:
function adder($a) {return function($b) {return $a+$b;}}
function index($i) {return function($a) {return $a[$i];}}
I'm sure you can think of useful examples.
Cheers,
Michael
MW>> function adder($a) {return function($b) {return $a+$b;}}
As opposed to:
function adder($a) { return create_function('$b', 'return '.(integer)$a.'+$b;'); }
Former form may be a bit prettier, but no substantial difference here.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
upload before it has been completed. Make it possible to handle big
uploads without requiring uploaded file to fit the memory. Handle multiple
This was changed in PHP 4.2.0, the file uploading code was rewritten
to not load the whole fie in memory.
--Jani
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
Already included, you may have seen this feature used before, <?php :-)
Ilia
Daniel Convissor wrote:
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
It would be nice if PHP could not get tripped up by "<?xml" tags when
short_tags is on.Already included, you may have seen this feature used before, <?php :-)
I gather he meant making the scanner intelligent enough to see that the <?
is followed by 'xml' and just ignoring the fact that short open tags is on.
I wouldn't expect to see it happen (or want it to), but if he wants it,
here's a sloppy implementation:
Index: Zend/zend_language_scanner.l
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131
diff -u -r1.131 zend_language_scanner.l
--- Zend/zend_language_scanner.l 3 Aug 2005 13:30:54 -0000
1.131
+++ Zend/zend_language_scanner.l 27 Aug 2005 21:55:36 -0000
@@ -1379,6 +1379,12 @@
}
}
+<INITIAL>"<?xml"([ \t]|{NEWLINE}) {
-
zendlval->value.str.val = (char *) estrndup(yytext, yyleng); -
zendlval->value.str.len = yyleng; -
zendlval->type = IS_STRING; -
return T_INLINE_HTML;
+}
<INITIAL>"<%="|"<?=" {
if ((yytext[1]=='%' && CG(asp_tags)) || (yytext[1]=='?' &&
CG(short_tags))) {
Let's just nuke all other opening tags than <?php
and we're done. :)
(-1000000 to adding <?xml in the scanner)
--Jani
It would be nice if PHP could not get tripped up by "<?xml" tags when
short_tags is on.Already included, you may have seen this feature used before, <?php :-)
I gather he meant making the scanner intelligent enough to see that the <? is
followed by 'xml' and just ignoring the fact that short open tags is on. I
wouldn't expect to see it happen (or want it to), but if he wants it, here's a
sloppy implementation:Index: Zend/zend_language_scanner.l
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131
diff -u -r1.131 zend_language_scanner.l
--- Zend/zend_language_scanner.l 3 Aug 2005 13:30:54 -0000 1.131
+++ Zend/zend_language_scanner.l 27 Aug 2005 21:55:36 -0000
@@ -1379,6 +1379,12 @@
}
}+<INITIAL>"<?xml"([ \t]|{NEWLINE}) {
zendlval->value.str.val = (char *) estrndup(yytext, yyleng);zendlval->value.str.len = yyleng;zendlval->type = IS_STRING;return T_INLINE_HTML;+}
<INITIAL>"<%="|"<?=" {
if ((yytext[1]=='%' && CG(asp_tags)) || (yytext[1]=='?' &&
CG(short_tags))) {
--
Donate @ http://pecl.php.net/wishlist.php/sniper
Hi Sara,
+<INITIAL>"<?xml"([ \t]|{NEWLINE}) {
And what's with <?xml-stylesheet ?> or any other processing instruction? Even
so others than xml are rarely used it would imho be a great wtf factor if
<?xml is somehow special.
At a sidenote: If you output xml you anyways neet to set the right
content-type header, so either set default_mimetype to text/xml (or similar)
and turn of short_open_tags in the php.ini or start the file with a header()
call followed by an echo of the xml-pi.
johannes
Johannes Schlueter wrote:
Hi Sara,
+<INITIAL>"<?xml"([ \t]|{NEWLINE}) {
And what's with <?xml-stylesheet ?> or any other processing instruction? Even
so others than xml are rarely used it would imho be a great wtf factor if
<?xml is somehow special.At a sidenote: If you output xml you anyways neet to set the right
content-type header, so either set default_mimetype to text/xml (or similar)
and turn of short_open_tags in the php.ini or start the file with aheader()
call followed by an echo of the xml-pi.
If you replace the te following lines:
<INITIAL>"<?"|"<script"{WHITESPACE}+"language"{WHITESPACE}"="{WHITESPACE}("php"|""php""|"'php'"){WHITESPACE}">" {
HANDLE_NEWLINES(yytext, yyleng);
if (CG(short_tags) || yyleng>2) { / yyleng>2 means it's not <? but <script> */
with:
<INITIAL>"<? "|"<script"{WHITESPACE}+"language"{WHITESPACE}"="{WHITESPACE}("php"|""php""|"'php'"){WHITESPACE}">" {
HANDLE_NEWLINES(yytext, yyleng);
if (CG(short_tags) || yyleng>3) { / yyleng>3 means it's not <? but <script> */
(notice the space behind '?' and the length check from 2 to 3) Wouldn't
that fix the whole problem without creating a special case for <?xml ?
David
Hi, David,
If you replace the te following lines:
<INITIAL>"<?"|"<script"{WHITESPACE}+"language"{WHITESPACE}"="{WHITESPACE}
<script> */ with: <INITIAL>"<? "|"<script"{WHITESPACE}+"language"{WHITESPACE}*"="{WHITESPACE}*("php"|"\"ph p\""|"\'php\'"){WHITESPACE}*">" { HANDLE_NEWLINES(yytext, yyleng); if (CG(short_tags) || yyleng>3) { /* yyleng>3 means it's not <? but <script> */ (notice the space behind '?' and the length check from 2 to 3) Wouldn't that fix the whole problem without creating a special case for <?xml ?
("php"|""php""|"'php'"){WHITESPACE}">" { HANDLE_NEWLINES(yytext,
yyleng);
if (CG(short_tags) || yyleng>2) { / yyleng>2 means it's not <? but
Wouldn't that break <?my_great_Function(); ?>?
johannes
Yep. I saw this happening during the PHP 5 coding contest we held last year
at Zend - some people used short open tags so I had to have that 'on' in my
php.ini to test, but having it 'on' screwed the entries that used XML, so I
was forever switching short open tags off and on.
I was supposed to prove that there was a problem in that area, at the time,
having opened my mouth over this issue.
<regret>I didn't actually make time to do so</regret>
- but yes, I believe it's an issue.
----- Original Message -----
From: "Sara Golemon" pollita@php.net
To: internals@lists.php.net
Sent: Sunday, August 28, 2005 12:02 AM
Subject: Re: [PHP-DEV] PHP 6.0 Wishlist
It would be nice if PHP could not get tripped up by "<?xml" tags when
short_tags is on.Already included, you may have seen this feature used before, <?php :-)
I gather he meant making the scanner intelligent enough to see that the <?
is followed by 'xml' and just ignoring the fact that short open tags is
on.
I wouldn't expect to see it happen (or want it to), but if he wants it,
here's a sloppy implementation:Index: Zend/zend_language_scanner.l
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131
diff -u -r1.131 zend_language_scanner.l
--- Zend/zend_language_scanner.l 3 Aug 2005 13:30:54 -0000
1.131
+++ Zend/zend_language_scanner.l 27 Aug 2005 21:55:36 -0000
@@ -1379,6 +1379,12 @@
}
}+<INITIAL>"<?xml"([ \t]|{NEWLINE}) {
zendlval->value.str.val = (char *) estrndup(yytext, yyleng);zendlval->value.str.len = yyleng;zendlval->type = IS_STRING;return T_INLINE_HTML;+}
<INITIAL>"<%="|"<?=" {
if ((yytext[1]=='%' && CG(asp_tags)) || (yytext[1]=='?' &&
CG(short_tags))) {
My prefrerence would be for the interpreter to look for "<?\w" when
short tags is enabled (that was brace, question mark, white space), I
don't think i've ever come across an instance when a space or line
break wasn't used. I don't have a huge code repository handy but are
there any good counter examples live?
It seems that checking for whitespace (or the long tag) would resolve
all of the <?xml* issues, while retaining the majority of BC, and
hopefully allow PHP to do what it does best, work the way developers
expect it to.
paul
Yep. I saw this happening during the PHP 5 coding contest we held last year
at Zend - some people used short open tags so I had to have that 'on' in my
php.ini to test, but having it 'on' screwed the entries that used XML, so I
was forever switching short open tags off and on.I was supposed to prove that there was a problem in that area, at the time,
having opened my mouth over this issue.<regret>I didn't actually make time to do so</regret>
- but yes, I believe it's an issue.
----- Original Message -----
From: "Sara Golemon" pollita@php.net
To: internals@lists.php.net
Sent: Sunday, August 28, 2005 12:02 AM
Subject: Re: [PHP-DEV] PHP 6.0 WishlistIt would be nice if PHP could not get tripped up by "<?xml" tags when
short_tags is on.Already included, you may have seen this feature used before, <?php :-)
I gather he meant making the scanner intelligent enough to see that the <?
is followed by 'xml' and just ignoring the fact that short open tags is
on.
I wouldn't expect to see it happen (or want it to), but if he wants it,
here's a sloppy implementation:Index: Zend/zend_language_scanner.l
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131
diff -u -r1.131 zend_language_scanner.l
--- Zend/zend_language_scanner.l 3 Aug 2005 13:30:54 -0000
1.131
+++ Zend/zend_language_scanner.l 27 Aug 2005 21:55:36 -0000
@@ -1379,6 +1379,12 @@
}
}+<INITIAL>"<?xml"([ \t]|{NEWLINE}) {
zendlval->value.str.val = (char *) estrndup(yytext, yyleng);zendlval->value.str.len = yyleng;zendlval->type = IS_STRING;return T_INLINE_HTML;+}
<INITIAL>"<%="|"<?=" {
if ((yytext[1]=='%' && CG(asp_tags)) || (yytext[1]=='?' &&
CG(short_tags))) {--
--
--
Paul Reinheimer
Zend Certified Engineer
Paul Reinheimer wrote:
My prefrerence would be for the interpreter to look for "<?\w" when
short tags is enabled (that was brace, question mark, white space), I
don't think i've ever come across an instance when a space or line
break wasn't used. I don't have a huge code repository handy but are
there any good counter examples live?
Thousands. <?=$foo?> and <?echo $foo?> are both extremely common when
injection single PHP variables into forms and general HTML sections.
-Rasmus
But why doesn't <?php=$foo ?> work? If that'd work, I just might start using
<?php ?>
Ron
"Rasmus Lerdorf" rasmus@lerdorf.com wrote in message
news:43114C03.1070902@lerdorf.com...
Paul Reinheimer wrote:
My prefrerence would be for the interpreter to look for "<?\w" when
short tags is enabled (that was brace, question mark, white space), I
don't think i've ever come across an instance when a space or line
break wasn't used. I don't have a huge code repository handy but are
there any good counter examples live?Thousands. <?=$foo?> and <?echo $foo?> are both extremely common when
injection single PHP variables into forms and general HTML sections.-Rasmus
Using <?php=$var ?> seems ridiculous, because it would be implemented
only into current branches, so it would not bring compatibility with
older releases...
Moreover, instead of using <?=$var ?> for variable interpolation, I
prefer to use the heredoc syntax, I think it's better for good looking
and readable code.
For that, I don't see any reason to create any new short_open_tag like
config directive...
Cyp
Ron Korving wrote:
But why doesn't <?php=$foo ?> work? If that'd work, I just might start using
<?php ?>Ron
"Rasmus Lerdorf" rasmus@lerdorf.com wrote in message
news:43114C03.1070902@lerdorf.com...Paul Reinheimer wrote:
My prefrerence would be for the interpreter to look for "<?\w" when
short tags is enabled (that was brace, question mark, white space), I
don't think i've ever come across an instance when a space or line
break wasn't used. I don't have a huge code repository handy but are
there any good counter examples live?Thousands. <?=$foo?> and <?echo $foo?> are both extremely common when
injection single PHP variables into forms and general HTML sections.-Rasmus
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:
-
named parameters.
in user functions, but also in core functions:
$result = in_array(needle: "foo", haystack: $array); -
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). -
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. -
improved __toString behavior
-
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). -
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
Hello Ron,
Wednesday, August 31, 2005, 3:37:51 PM, you wrote:
- 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).
You can already do that with 5.1 by adding three lines of code.
- improved __toString behavior
I'll take care of that asap.
- 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.
That might be the case because a) the underlying library does not allow this
or because the extension isn't updated. In general all file functions should
accept any stream. Maybe you need to look into the extension source yourself
or contact the author/maintainer.
Best regards,
Marcus
"Marcus Boerger" helly@php.net wrote in message
news:361587231.20050831205522@marcus-boerger.de...
Hello Ron,
Wednesday, August 31, 2005, 3:37:51 PM, you wrote:
- 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).You can already do that with 5.1 by adding three lines of code.
Sounds awesome.. is this documented (I don't mean the PHP manual) anywhere?
I'm curious as to how this works.
- improved __toString behavior
I'll take care of that asap.
You're my hero.
- 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.That might be the case because a) the underlying library does not allow
this
or because the extension isn't updated. In general all file functions
should
accept any stream. Maybe you need to look into the extension source
yourself
or contact the author/maintainer.
I looked into the source, but I'm I couldn't quite grasp the inner workings.
I promised myself to get into more actively "developing" in this area, maybe
apply for a CVS account in time... but that's gonna take some time. Where do
I see who maintains a certain extension?
Best regards,
Marcus
Thanks Marcus,
Ron
Hello Ron,
Wednesday, August 31, 2005, 9:02:37 PM, you wrote:
"Marcus Boerger" helly@php.net wrote in message
news:361587231.20050831205522@marcus-boerger.de...Hello Ron,
Wednesday, August 31, 2005, 3:37:51 PM, you wrote:
- 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).You can already do that with 5.1 by adding three lines of code.
Sounds awesome.. is this documented (I don't mean the PHP manual) anywhere?
I'm curious as to how this works.
Look for slide 42 in talk 'SPL for the masses' here: http://talks.somabo.de
- improved __toString behavior
I'll take care of that asap.
You're my hero.
- 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.That might be the case because a) the underlying library does not allow
this
or because the extension isn't updated. In general all file functions
should
accept any stream. Maybe you need to look into the extension source
yourself
or contact the author/maintainer.
I looked into the source, but I'm I couldn't quite grasp the inner workings.
I promised myself to get into more actively "developing" in this area, maybe
apply for a CVS account in time... but that's gonna take some time. Where do
I see who maintains a certain extension?
look into the EXTENSIONS file or in the head of any .h or .h file.
marcus
Hi,
- 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).You can already do that with 5.1 by adding three lines of code.
Sounds awesome.. is this documented (I don't mean the PHP manual)
anywhere?
I'm curious as to how this works.Look for slide 42 in talk 'SPL for the masses' here:
http://talks.somabo.de
Oh my god, I am so ashamed (hangs head between knees)... sorry.
I looked into the source, but I'm I couldn't quite grasp the inner
workings.
I promised myself to get into more actively "developing" in this area,
maybe
apply for a CVS account in time... but that's gonna take some time.
Where do
I see who maintains a certain extension?look into the EXTENSIONS file or in the head of any .h or .h file.
marcus
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
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[].
Containing what? What about those "round-robin" environments where
you have several machines serving same web pages?
--Jani
Jani Taskinen schrieb:
Containing what? What about those "round-robin" environments where
you have several machines serving same web pages?
You're right, what we really need is being able to introduce new
super-globals through extensions (can we do this already?), so that the
extensions that talk to SRM and memcached, for instance, can do the
right thing.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Jani Taskinen schrieb:
Containing what? What about those "round-robin" environments where
you have several machines serving same web pages?You're right, what we really need is being able to introduce new
super-globals through extensions (can we do this already?), so that the
Yes we can do this already. See ext/session/ for one example. :)
But I'd treat this kind of thing rather as part of session handling
mechanism though. We had a short thread about this in the "wishlist"
thread already so read that too.
--Jani
Jani Taskinen schrieb:
But I'd treat this kind of thing rather as part of session handling
mechanism though. We had a short thread about this in the "wishlist"
thread already so read that too.
Ah, now I remember. Anyways, just wanted to make sure that this does not
get forgotten ;-)
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Jani Taskinen wrote:
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[].Containing what?
A super-global like $_PERSISTENT could work like $_SESSION, with a
similar "framework", but could store data which is NOT user-specific
like session-data.
So you have a very simple methode to store any variables/objects between
HTTP-requests. If you use something like APC as backend, you will also
get a fast methode to store/load variables/objects, which are not
user-specific, and perhaps expensive to create/load (e.g. from a
webservice, DB...).
The problem with "several machines serving same web pages" is exactly
the same you have with $_SESSION today. But the session extension
provides means to work around this using a DB or memcached as backend.
This could be copied by something like a "Persistance Framework".
But many other PHP installations will have another problem you don't see
with $_SESSION today: concurrency. That's because you don't have a
unique session-ID anymore, so application1 can overwrite variables from
application2, script1.php can overwrite variables from script1.php and
on shared hosting setups user1 can overwrite variables from user2.
That's also a security issue.
So an application-ID has been a good idea, but if you have to define it
by yourself, chances are that two users choose the same application-ID
and applications will break. So perhaps you also have to find some other
values, the users cannot control, to avoid concurrency issues. Perhaps
make a $_PERSISTENT variable only available for the script which has
created it (by saving the path too, but if you move/rename..., and not
very flexible anymore).
Best regards
Andreas
PS: I've read the discussion on this list before ;-)