PHP Strict standards:Declaration of … should be compatible with that of…
今天把原来一份很老的PHP代码导入到了PaaS上，出现了许多Strict standards:Declaration of … should be compatible with that of…这样的错误，字面意思好像是说函数不匹配，看了下出错的函数，都是子类重写的基类函数。
上网搜索了一下，发现许多帖子基本都抄的一样，说什么这是由于 php5.3版本后，要求继承类必须在父类之后定义，如果父类定义在前，继承类在后，就不会出现这个错误。尤其是http://bugs.php.net/bug.php?id=46851上面还煞有介事的给出了正反例：
|
1
2
3
4
5
6
7
8
9
|
<?php
// this code does trigger a strict message
error_reporting
( E_ALL | E_STRICT );
class
cc
extends
c {
function
test() {
return
null; } }
class
c {
function
test(
$a
) {
return
1; } }
$cc
=
new
cc();
?>
|
|
1
2
3
4
5
6
7
8
9
|
<?php
// this code does NOT trigger a strict message
error_reporting
( E_ALL | E_STRICT );
class
c {
function
test(
$a
) {
return
1; } }
class
cc
extends
c {
function
test() {
return
null; } }
$cc
=
new
cc();
?>
|
并且讨论了出错的情况多半是由于用_autoload()对类进行自动的include，导致基类的定义在后面，子类定义在前面。
我看了下自己的代码，虽然确实也用到了autoload，但是都是显式的先导入了几个基类，并不存在这样的情况，而且将上面的正反例子试了一下，都会出现E_STRICT的警告。
真正原因：
其实如果子类重写方法的参数和基类不一样，只要给参数个默认值，使得编译器认为参数可以为空，保持重写方法与基类方法的函数签名相同就可以了。
经常用JAVA的同学肯定知道，在JAVA或者C++中，重写方法的函数签名本应该就和基类函数是一致的，我认为这也是符合自然规律的，因为override本来就是覆盖的意思嘛，既然覆盖了，那么就应该和原函数一致，不然怎么能“盖”的住呢~并且方法的重写多用在重写虚函数或者更明白的说就是重写接口的函数，如果重写的时候函数签名都不一致了，还要接口干嘛呢。。。
所以PHP的新版本中，我觉得定义这个E_STRICT的警告错误是很有用处的，要提醒程序员自己的重写方法到底对不对。
最后还是鄙视一下上面那些抄来抄去的帖子，如果某个语言连基类和子类定义的顺序都不能打乱，说明这个编译器非常有问题了，显然是bug。。。