Page 1 of 1

abstarct static inconsistent error handling, 5.2.6

Posted: Thu Nov 11, 2010 10:07 am
by jamInTheValleys
Hello,

If I have an index file with:

Code: Select all

date_default_timezone_set('GMT');
error_reporting(E_ALL | E_STRICT); 

abstract class A {
    abstract public static function YesIReallyMeanAbstractStatic();
}

class B extends A {
    public static function YesIReallyMeanAbstractStatic() {
    }
}
This will not error.

However if I have:

Code: Select all

date_default_timezone_set('GMT');
error_reporting(E_ALL | E_STRICT); 

require('class_a_in_a_different_file.php'); // Or use __autoload() to do the same.

class B extends A {
    public static function YesIReallyMeanAbstractStatic() {
    }
}
This will throw the error:
"Static function A::YesIReallyMeanAbstractStatic() should not be abstract"

I know abstract statics are debatable...
but it makes no sense to me for it to be allowed in the first example but disallowed in other.

So I was wondering if this is a bug? Or is there something else going on here?

I assume the parser is evaluating the included file and then throwing the error which doesn't happen if both classes are in the same file as they can then be evaluated altogether.

Re: abstarct static inconsistent error handling, 5.2.6

Posted: Thu Nov 11, 2010 10:49 am
by Darhazer
Pretty interesting.
If you execute just the required file, it works
It generates an error only in the file, that includes the definition of A

And it's the same behavior in PHP 5.3.2

Re: abstarct static inconsistent error handling, 5.2.6

Posted: Thu Nov 11, 2010 11:27 am
by requinix
That error is a compile-time error. In the first example the error reporting stuff hasn't happened yet so your default error reporting settings are the ones in effect (which, apparently, don't show E_STRICT messages).

Re: abstarct static inconsistent error handling, 5.2.6

Posted: Thu Nov 11, 2010 11:37 am
by Weirdan
tasairis's explanation seems to be correct - if I set error reporting from command-line it complains even for first file:

Code: Select all

weirdan@virtual-debian-home:~$ php -derror_reporting=`php -r'echo E_ALL|E_STRICT|E_DEPRECATED;'` q.php
PHP Strict standards:  Static function A::YesIReallyMeanAbstractStatic() should not be abstract in /home/weirdan/q.php on line 6
weirdan@virtual-debian-home:~$ php -v
PHP 5.3.3-2 with Suhosin-Patch (cli) (built: Oct 21 2010 18:58:27)

Re: abstarct static inconsistent error handling, 5.2.6

Posted: Fri Nov 12, 2010 6:56 am
by jamInTheValleys
Cheers, that makes sense.

Do you think it's expected behaviour? I would have thought error_reporting() should kick in immediately.

If it's not I do a bug report.

Re: abstarct static inconsistent error handling, 5.2.6

Posted: Fri Nov 12, 2010 8:04 am
by Weirdan
jamInTheValleys wrote: Do you think it's expected behaviour? I would have thought error_reporting() should kick in immediately.
It's the only logical behaviour anyway - imagine you set your error_reporting depending on client's ip - PHP wouldn't know the value it will be set to up until the code actually executes. So it uses whatever is set in php.ini / .htaccess / php-fpm.conf / etc until you explicitly change it via error_reporting() function call, and function calls can only happen at runtime.

Re: abstarct static inconsistent error handling, 5.2.6

Posted: Fri Nov 12, 2010 8:26 am
by jamInTheValleys
I see.

It's evaluating and compiling the first example with the default error reporting type (which isn't E_STRICT in this example) and then executes it.

In the second example it evaluates and compiles the first file, runs it, sets the error reporting to E_STRICT and then evaluates the second file which throws the compile error.

I guess the answer is to not do php config in the script :) Unless I need to switch it for some reason.

Re: abstarct static inconsistent error handling, 5.2.6

Posted: Fri Nov 12, 2010 11:40 am
by requinix
jamInTheValleys wrote:I guess the answer is to not do php config in the script :) Unless I need to switch it for some reason.
You can, but it won't affect compile errors in the current script. It will work as expected for anything that gets included or otherwise interpreted later.