博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
PHP Strict standards:Declaration of … should be compatible with that of…(转)
阅读量:6256 次
发布时间:2019-06-22

本文共 1267 字,大约阅读时间需要 4 分钟。

今天把原来一份很老的PHP代码导入到了PaaS上,出现了许多Strict standards:Declaration of … should be compatible with that of…这样的错误,字面意思好像是说函数不匹配,看了下出错的函数,都是子类重写的基类函数。

上网搜索了一下,发现许多帖子基本都抄的一样,说什么这是由于 php5.3版本后,要求继承类必须在父类之后定义,如果父类定义在前,继承类在后,就不会出现这个错误。尤其是上面还煞有介事的给出了正反例:

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

转载于:https://www.cnblogs.com/xingmeng/p/3193373.html

你可能感兴趣的文章
Redis高级特性介绍及实例分析
查看>>
Android的复选框的详细开发案例分析
查看>>
iOS FMDB数据库之增删改查使用
查看>>
EventBus源码解析
查看>>
Android中绘制简单几何图形和路径Path
查看>>
Internationalization(i18n) support in SAP CRM,UI5 and Hybris
查看>>
Xcode Debug调试汇总
查看>>
设计模式:再严谨的单例也尽量不要使用
查看>>
TiDB at 丰巢:尝鲜分布式数据库
查看>>
三篇文章了解 TiDB 技术内幕 —— 谈调度
查看>>
Next.js踩坑入门系列(六) —— 再次重构目录
查看>>
1. Context - React跨组件访问数据的利器
查看>>
Git常用操作、提交到GitHub等
查看>>
Android基础 四大组件之广播(Broadcast)
查看>>
SQL优化器原理 - 查询优化器综述
查看>>
TODO list小工具,给自己一个交代
查看>>
iOS Notification 与多线程
查看>>
NLP系列学习:概率图模型简述
查看>>
数组分页,返回数据,你用过吗?
查看>>
JEESZ-kafka消息服务平台实现
查看>>