On Tue, 23 Dec 2003, Edin Kadribasic wrote:
> Yes it was clearly agreed that for the sake of PEAR and others E_STRICT
> should not be a part of E_ALL. Derick's probably getting too old to
> remember things correctly :)
Uhm? This is not what we were talking about Edin.
Derick
--
PHP Internals -
At 02:07 PM 12/23/2003 +0100, Derick Rethans wrote:
On Tue, 23 Dec 2003, Andi Gutmans wrote:
> I disagree with Derick and I thought we agreed that the default would stay
> E_ALL and not E_ALL|E_STRICT.
I missed your point, why do you want this?
a) BC
b) Because we agreed that E_STRICT is only fo
On Tue, 23 Dec 2003 14:04:41 +0100
Edin Kadribasic <[EMAIL PROTECTED]> wrote:
> Yes it was clearly agreed that for the sake of PEAR and others
> E_STRICT should not be a part of E_ALL. Derick's probably getting too
> old to remember things correctly :)
A countless agreement here :). Obviously for
On Tue, 23 Dec 2003, Andi Gutmans wrote:
> I disagree with Derick and I thought we agreed that the default would stay
> E_ALL and not E_ALL|E_STRICT.
I missed your point, why do you want this?
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
On Tuesday, Dec 23, 2003, at 13:54 Europe/Copenhagen, Andi Gutmans
wrote:
At 01:46 PM 12/23/2003 +0100, Christian Schneider wrote:
Derick Rethans wrote:
I would like to see E_STRICT added by default otherwise things start
out
getting way too complex.
As mentioned here on the list I added E_STRIC
Andi Gutmans wrote:
I disagree with Derick and I thought we agreed that the default would
stay E_ALL and not E_ALL|E_STRICT.
Oh, I misunderstood you comment then.
I don't really have an opinion on E_ALL vs. E_ALL|E_STRICT, as soon as
you and Derick sort it out I'll adapt my patch (or you can mak
At 01:46 PM 12/23/2003 +0100, Christian Schneider wrote:
Derick Rethans wrote:
I would like to see E_STRICT added by default otherwise things start out
getting way too complex.
As mentioned here on the list I added E_STRICT to the patch two days ago,
now I'm curious if someone with karma will appl
Derick Rethans wrote:
I would like to see E_STRICT added by default otherwise things start out
getting way too complex.
As mentioned here on the list I added E_STRICT to the patch two days
ago, now I'm curious if someone with karma will apply it ;-)
- Chris
--
PHP Internals - PHP Runtime Develop
On Mon, 22 Dec 2003, Christian Schneider wrote:
> Andi Gutmans wrote:
> > Why not make the default catch-all as E_ALL and add to the documentation
> > that the new E_STRICT option needs to be turned on explicitly?
>
> Just using E_ALL would match error_reporting where the default E_ALL
> does not
At 11:01 AM 12/22/2003 +0100, Christian Schneider wrote:
Andi Gutmans wrote:
Why not make the default catch-all as E_ALL and add to the documentation
that the new E_STRICT option needs to be turned on explicitly?
Just using E_ALL would match error_reporting where the default E_ALL does
not includ
Andi Gutmans wrote:
Why not make the default catch-all as E_ALL and add to the documentation
that the new E_STRICT option needs to be turned on explicitly?
Just using E_ALL would match error_reporting where the default E_ALL
does not include E_STRICT. Including E_STRICT would match the old
docum
Why not make the default catch-all as E_ALL and add to the documentation
that the new E_STRICT option needs to be turned on explicitly? It's not as
if the PHP 4 manual is the bible and you wouldn't break BC. Or am I missing
something again?
Andi
At 09:30 PM 12/21/2003 +0100, Christian Schneide
Derick Rethans wrote:
By browsing over it it seems that this patch looks wrong, as you forgot
to add E_STRICT to E_ALL in line 944 and it would also be better to use
zend_parse_parameters.
Thanks for your help on improving the patch.
I used E_ALL because that's what was proposed by people here on
On Sat, 20 Dec 2003, Christian Schneider wrote:
> Andi Gutmans wrote:
> > Anyway, I very strongly feel that an additional optional argument to
> > set_error_handler() is the right way to go.
> >
> > Let's go this way!
>
> A patch for PHP5 accomplishing this can be found at:
> http://cschneid.com/p
Christian Schneider wrote:
A patch for PHP5 accomplishing this can be found at:
http://cschneid.com/php/php5/set_error_handler_reporting_parameter.patch
I updated the patch to keep a stack of the error_reporting level so
restore_error_handler works as expected.
- Chris
--
PHP Internals - PHP Run
Zeev Suraski wrote:
Sure there is. You may shut off (or otherwise configure) error
reporting site-wide, or application-wide, whereas you'd use the error
handler only in parts of the app/site.
No one keeps you from changing the error_reporting level at certain
points in your application so I can
On Sat, Dec 20, 2003 at 01:06:25AM +0200, Zeev Suraski wrote:
> Sure there is. You may shut off (or otherwise configure) error reporting
> site-wide, or application-wide, whereas you'd use the error handler only in
> parts of the app/site.
Oh, I see what you mean. Yeah, problems would be caus
On Sat, Dec 20, 2003 at 12:51:15AM +0100, Derick Rethans wrote:
>
> As another guy said "lets nominate him as the mlemos of the quarter"
Derick, I guess this inside joke comparing me to Manuel is meant as some
sort of insult. Doesn't reflect well on you, or the PHP development
community.
--Dan
Andi Gutmans wrote:
Anyway, I very strongly feel that an additional optional argument to
set_error_handler() is the right way to go.
Let's go this way!
A patch for PHP5 accomplishing this can be found at:
http://cschneid.com/php/php5/set_error_handler_reporting_parameter.patch
- Chris
--
PHP Int
On Fri, 19 Dec 2003, Daniel Convissor wrote:
> On Sat, Dec 20, 2003 at 12:31:31AM +0200, Andi Gutmans wrote:
> >
> > Yeah but in PHP 5 you have the extra argument. It's no problem to make the
> > PHP 4 script use this.
>
> This and your last post are rehasing points I've already debunked a few
> t
At 21:02 19/12/2003, Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 08:15:15PM +0200, Zeev Suraski wrote:
>
> You may very well shut all errors off in
> production code, and rely on everything going through your error
> handler.
That already happens in ALL code which utilizes user defined error
pr
At 20:28 19/12/2003, Christian Schneider wrote:
Zeev Suraski wrote:
argument makes a great deal of sense. As a matter of fact, in practice -
you can easily get forward-compatibility. Just supply it in both PHP 4
and 5 - extra arguments are ignored anyway (just provide @ to make sure
of that).
On Sat, Dec 20, 2003 at 12:31:31AM +0200, Andi Gutmans wrote:
>
> Yeah but in PHP 5 you have the extra argument. It's no problem to make the
> PHP 4 script use this.
This and your last post are rehasing points I've already debunked a few
times in this thread.
--Dan
--
T H E A N A L Y S I S
At 05:29 PM 12/19/2003 -0500, Daniel Convissor wrote:
On Sat, Dec 20, 2003 at 12:13:45AM +0200, Andi Gutmans wrote:
> At 03:59 PM 12/19/2003 -0500, Daniel Convissor wrote:
>
> >None the less, this wouldn't resolve the situation where loads of object
> >oriented code all of a sudden starts spewing v
On Sat, Dec 20, 2003 at 12:13:45AM +0200, Andi Gutmans wrote:
> At 03:59 PM 12/19/2003 -0500, Daniel Convissor wrote:
>
> >None the less, this wouldn't resolve the situation where loads of object
> >oriented code all of a sudden starts spewing var depricated messages.
> >Not fun.
>
> Those message
At 03:59 PM 12/19/2003 -0500, Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 09:55:22PM +0100, Michael Walter wrote:
>
> set_error_handler('foo');
> @set_error_handler('foo', E_ALL);
Nice!
None the less, this wouldn't resolve the situation where loads of object
oriented code all of a sudden start
On Fri, Dec 19, 2003 at 09:55:22PM +0100, Michael Walter wrote:
>
> set_error_handler('foo');
> @set_error_handler('foo', E_ALL);
Nice!
None the less, this wouldn't resolve the situation where loads of object
oriented code all of a sudden starts spewing var depricated messages.
Not fun.
--Dan
Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 08:49:10PM +0100, Andrey Hristov wrote:
So the code with @ is "working". The set_error_handler() is bailing out
and everything is ok
No, the erorr handler isn't being called and that's not okay.
--Dan
Well, you could simply do like
set_error_ha
On Fri, Dec 19, 2003 at 03:50:42PM -0500, John Coggeshall wrote:
>
> I think trying to stop an improvement because it's not PHP 4 compatible
> is a mistake.
We're not trying to stop an improvement, we're trying to define exactly
how to improve it.
--Dan
--
T H E A N A L Y S I S A N D
On Fri, Dec 19, 2003 at 03:48:23PM -0500, John Coggeshall wrote:
>
> I don't really see the issue with PHP 5 code not being able to be ran in
> PHP4. If that's the case, let's throw out all of the ZE2 OO stuff too
> because that's not PHP 4 compatible either.
:)
In the LONG term, rewriting appl
On Fri, 2003-12-19 at 10:13, Daniel Convissor wrote:
> I, and lots of people, need to worry about it. I write code that uses
> PHP. Much of it is for general public consumption. Some is for sale at
> significant cost. I have to write stuff once and have it work anywhere.
If you are concerned a
On Fri, 2003-12-19 at 09:43, Christian Schneider wrote:
> No, you were right. A script using
> set_error_handler("handler", error_reporting());
> will get "Wrong parameter count for set_error_handler()" for PHP4.
I don't really see the issue with PHP 5 code not being able to be ran in
PHP4. If tha
On Fri, Dec 19, 2003 at 08:49:10PM +0100, Andrey Hristov wrote:
> So the code with @ is "working". The set_error_handler() is bailing out
> and everything is ok
No, the erorr handler isn't being called and that's not okay.
--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
Daniel Convissor wrote:
Just supply it in both PHP 4 and 5 - extra arguments are ignored anyway
Nope...
CODE
echo phpversion();
set_error_handler('error_handler', 0);
function error_handler($code, $text) {
echo "Handled... $text";
}
$x;
OUTPUT
--
4.3.4
Warning: Wrong parameter
On Fri, Dec 19, 2003 at 08:15:15PM +0200, Zeev Suraski wrote:
>
> You may very well shut all errors off in
> production code, and rely on everything going through your error
> handler.
That already happens in ALL code which utilizes user defined error
processing. Once a custom error handler is
Christian Schneider wrote:
> Just checked it and no: set_error_handler does _not_ ignore the
> additional parameter, it fails and does _not_ install the handler on
> PHP4. Leave out E_ALL and it works like a charm. Am I missing something
> here?
>
> Script used to test:
> function handler()
> {
>
Zeev Suraski wrote:
argument makes a great deal of sense. As a matter of fact, in practice
- you can easily get forward-compatibility. Just supply it in both PHP
4 and 5 - extra arguments are ignored anyway (just provide @ to make
sure of that).
Just checked it and no: set_error_handler does _
Derick Rethans wrote:
What in your world is broken behavior might be a feature for somebody
else.
I do *not* want to remove a feature, I want to add one which is missing
badly!
Do you actually _read_ what people write? *sigh*
> Do you have any hard data to back those numbers up?
My sentence star
At 17:13 19/12/2003, Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 04:00:34PM +0100, Derick Rethans wrote:
>
> Don't worry about this, as PHP wasnever really forwards compatible
> anyway.
I, and lots of people, need to worry about it. I write code that uses
PHP. Much of it is for general public
On Fri, 19 Dec 2003, Christian Schneider wrote:
> My guess of the chance that this happens? I'd say about 1:2^42. This
> script working without changes with PHP5? About 1:2^64738. And a web
> hosting company with customers like that upgrading to PHP5 anytime soon?
> About 1:2^64.
Do you have any
On Fri, 19 Dec 2003, Christian Schneider wrote:
> Why make life harder for 99.99% of the PHP users for this one
> hypothetical case? I think we're doing mental masturbation instead of
> simply fixing broken behaviour.
What in your world is broken behavior might be a feature for somebody
else.
De
On Fri, Dec 19, 2003 at 07:02:49PM +0200, Lenar Lõhmus wrote:
> Now there
> are plenty of PHP scripts and projects just sitting somewhere but abandoned
> by their creators waiting to be downloaded. That script/project could use
> custom error handlers and could somehow depend on PHP4's behaviour.
Lenar Lõhmus wrote:
by their creators waiting to be downloaded. That script/project could use
custom error handlers and could somehow depend on PHP4's behaviour. You
never know.
My guess of the chance that this happens? I'd say about 1:2^42. This
script working without changes with PHP5? About 1:2
Christian Schneider wrote:
> Ok, now realistically, how many people use error handlers, have
> error_reporting != E_ALL *AND* expect their handler to be called for
> E_ALL *AND* aren't savvy enough to simple set error_reporting to E_ALL?
Even though I'm not one of them I'm told there are people w
Lenar Lõhmus wrote:
But it's not good either stopping my error_handler from being called in PHP5
accordingly to error_reporting() value. This way I might not notice my
error handler isn't getting all calls it used to (depends on conf). So IMHO
silent behavior change is still worse.
Ok, now realisti
> Please provide a real world example of why you would need version compare.
I wouldn't :)
> Error handlers written for PHP 4 (expecting that all errors will go to the
> handler) will operate just fine under the new system (where only errors
> meeting the error reporting mask get sent to the handl
On Fri, 19 Dec 2003, Lenar [ISO-8859-1] Lõhmus wrote:
> Christian Schneider wrote:
>
> > Daniel Convissor wrote:
> >> Adding an optional argument has the worst of both worlds. In order to
> >> take advantage of it, one must lock your code into PHP 5.
>
> It doesn't work this way in PHP4 anyway. S
On Fri, Dec 19, 2003 at 06:06:40PM +0200, Lenar Lõhmus wrote:
>
> It doesn't work this way in PHP4 anyway. So if you really must use this
> feature (I think I would) you can live with being locked to PHP5.
But then in order to have an error handler work in both PHP 5 and PHP 4
while avoiding the
Christian Schneider wrote:
> Daniel Convissor wrote:
>> Adding an optional argument has the worst of both worlds. In order to
>> take advantage of it, one must lock your code into PHP 5.
It doesn't work this way in PHP4 anyway. So if you really must use this
feature (I think I would) you can liv
Daniel Convissor wrote:
I, and lots of people, need to worry about it. I write code that uses
I second that.
Adding an optional argument has the worst of both worlds. In order to
take advantage of it, one must lock your code into PHP 5.
In this specific case I can live with an optional argument
On Fri, Dec 19, 2003 at 04:00:34PM +0100, Derick Rethans wrote:
>
> Don't worry about this, as PHP wasnever really forwards compatible
> anyway.
I, and lots of people, need to worry about it. I write code that uses
PHP. Much of it is for general public consumption. Some is for sale at
signific
On Fri, 19 Dec 2003, Christian Schneider wrote:
> Daniel Convissor wrote:
> > On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
> >
> >>It is when it's optional and the default is the current behavior.
> >
> > Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
>
> No
Daniel Convissor wrote:
On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
It is when it's optional and the default is the current behavior.
Pardon me. Looks like PHP 3 behavior is still stuck in my brain...
No, you were right. A script using
set_error_handler("handler", error_report
On Fri, Dec 19, 2003 at 03:20:17PM +0100, Derick Rethans wrote:
> On Fri, 19 Dec 2003, Daniel Convissor wrote:
> >
> > But then scripts written with the proposed second argument will not be
> > backwards compatable.
>
> It is when it's optional and the default is the current behavior.
Pardon me.
On Fri, 19 Dec 2003, Daniel Convissor wrote:
> On Fri, Dec 19, 2003 at 10:38:00AM -, Ford, Mike [LSS] wrote:
> >
> > How about a new optional 2nd argument to set_error_handler?
>
> But then scripts written with the proposed second argument will not be
> backwards compatable.
It
On Fri, Dec 19, 2003 at 10:38:00AM -, Ford, Mike [LSS] wrote:
>
> How about a new optional 2nd argument to set_error_handler?
But then scripts written with the proposed second argument will not be
backwards compatable.
I like the idea put forth earlier about only calling custom
At 12:00 PM 12/19/2003 +0100, Christian Schneider wrote:
Mike Ford wrote:
How about a new optional 2nd argument to set_error_handler?
Sounds like a good idea to me. Could be the mask of errors one wants to
get in the error handler.
So one could do
set_error_handler("handler", E_ALL);# Default
At 10:38 AM 12/19/2003 +, Ford, Mike [LSS] wrote:
On 18 December 2003 23:38, Andi Gutmans wrote:
> At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote:
> I agree wholeheartedly, especially since one can set
> reporting to E_ALL and
> then ignore whatever one likes but with th
Mike Ford wrote:
How about a new optional 2nd argument to set_error_handler?
Sounds like a good idea to me. Could be the mask of errors one wants to
get in the error handler.
So one could do
set_error_handler("handler", E_ALL); # Default, current mode
set_error_handler("handler", error_reporting
On 18 December 2003 23:38, Andi Gutmans wrote:
> At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote:
> I agree wholeheartedly, especially since one can set
> reporting to E_ALL and
> then ignore whatever one likes but with the way it is now
> there is no way
> of not being called for everythi
At 10:17 PM 12/18/2003 +0100, Christian Schneider wrote:
I agree wholeheartedly, especially since one can set reporting to E_ALL and
then ignore whatever one likes but with the way it is now there is no way
of not being called for everything.
If you want I could provide patches which
a) fix the
Andi Gutmans wrote:
Yeah this is a known bug and will have to be fixed in RC1. It's not a
showstopper for B3.
Yes, this bug has indeed nothing to do with B3. I just though that PHP5
would maybe be the time to make set_error_handler finally usable.
In any case, I do think that the custom error ha
62 matches
Mail list logo
