class implem implements constr {
function __construct ($a) {
}
}
这段代码在 PHP5.0和 PHP 5.1 里面运行是毫无问题的，但在 PHP 5.2中则会抛出一个错误：Fatal error: Declaration of implem::__construct() must be compatible with that of constr::__construct()，提示类implem 的构造函数与接口constr 的构造函数的声明不匹配。
值得一提的是这项新特性的添加过程是很有意思。，有兴趣的朋友可以到Zend 的每周总结（http://www.zend.com/zend/week/week279.php#Heading9）里面看看来龙去脉，此处不再赘述。
5、__toString() 函数将会在任何合适的地方被调用。
魔术方法 __toString() 现在会在一个字符串上下文环境中被调用。换句话说，一个对象在任何地方都可以作为一个字符串来使用，只要它实现了 __toString() 函数。当然你实现的 __toString() 函数不能抛出异常，否则脚本将会中止运行。以前为防万一，PHP 5.0/5.1会在必要时会把对象标识(Id)作为一个字符串返回，这个特性在 PHP 5.2中已经被抛弃。因此这带来的问题就可能是不能保证一个对象的标识总是唯一的。如果你在程序中利用了对象标识符的唯一性，那这将会是某种缺陷。如果没有实现类的 __toString()函数但却把其对象作为作为一个字符串来使用就会导致一个“可捕捉的致命错误”。 还有个特例，就是对象也不能作为作为数组的索引或者键名，即使是它有一个 __toString() 方法。以后 PHP 可能会内建一个 Hash机制来提供对对象唯一性的支持，但就现在来说，你必须自己提供一个对象的 hash 算法，或者干脆就用新提供的 SPL 函数：spl_object_hash()；
6、为在写模式下访问 __get() 的返回值这种情况增加了E_NOTICE 级错误提示。
显然 __get() 函数只能在读模式下返回一个值，并且也不可能把一个值写入 __get() 函数。但在以前的版本中并没有为这种不正确的用法给予提示。从 PHP 5.2 开始将会为这种情况抛出一个E_NOTICE。注意：如果你对 foreach() 和其他的一些更改数组内部指针的函数也采取了同样的操作（即给 foreach 所“抽”出来的值进行赋值），那也会触发一个E_NOTICE ，因为这些“抽”出来的值都是处于读模式。如果你的代码中存在这种情况，那你应该把 __get() 函数的返回值转换为一个数组，或者用 SPL 里面的ArrayObject 来代替这个数组。
7、丢弃了抽象静态的类函数。
由于“笔漏”，PHP 5.0和5.1 版本竟然允许类具有抽象静态函数，不过现在不行了。现在只允许接口有抽象静态函数。
8、其他一些语言特性的改变：
－ SPL 新增了正则迭代器(Regex Iterators)、文件对象（SplFileObject）的CSV 支持等。
－ 增加了对 RFC2397 （数据流）的支持。
－ 增加了对Apache 2.2的支持。
－ 现在可以在上传文件时实时取得文件的上传进度了。
－ 对PHP或其扩展所需 OpenSSL 库、PCRE 库、MySQL客户端库、PostgreSQL 客户端库、SQLite 库等均进行更新升级。
最后再来介绍一下 PHP 运行模式方面的改动：
1、首先是 PHP 5.2 改变了 Win32 环境下 PHPRC 环境变量的优先级。
在以前搜索 php.ini 的路径顺序为：
·SAPI 模块所指定的位置（Apache 2 中的 PHPIniDir 指令，CGI 和 CLI 中的 -c 命令行选项，NSAPI 中的 php_ini 参数，THTTPD 中的 PHP_INI_PATH 环境变量）
·HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath（Windows 注册表位置）
·PHPRC 环境变量
·当前工作目录（对于 CLI）
·web 服务器目录（对于 SAPI 模块）或 PHP 所在目录（Windows 下其它情况）
·Windows 目录（C:\windows 或 C:\winnt），或 –with-config-file-path 编译时选项指定的位置现在 PHPRC 环境变量由第三优先权变为第二优先权，高于Windows 注册表所指定的位置。
2、PHP 的命令行模式（CLI SAPI）不再在CWD（当前工作目录）里查找 php.ini 或php-cli.ini 文件。
在 PHP 5.1.x 中有一个未公开的特性就是 CLI会自动在当前目录中搜索 PHP 的配置文件。这种随便读入一个未经许可的配置文件的行为将可能会导致一个不可预知的错误。在 PHP 5.2 版本里已经将该特性移除，不再再在CWD（当前工作目录）里查找 php.ini 或php-cli.ini 文件了。
总结：
总体来说，从性能上 PHP 5.2 已经超越 PHP4.x成为目前速度最快的版本，从语言及安全特性上也是无出其右。即便是 PHP4.x 有一些代码缓存工具（如 eAccelerator）可以提高性能，但目前也已经有 APC、X-Cache等表示可以支持 5.2 版本（eAccelerator 可能还需要一段时间来完善）。虽然 APC 等在性能还略输于eAccelerator，但加上PHP5.2的种种优化措施，至少不会比 PHP4+eAccelerator 差到哪去更何况还有很要命的安全更新。既然如此，那我们还有什么理由不升级呢？同时我也推荐各大虚拟主机厂商将其服务器（至少是新增的服务器）更新为 PHP5.2版本。在不增加性能消耗的基础上还能为客户提供更多的语言特性，同时也增强了产品的竞争力，何乐而不为呢？
让我们开始全面进入 PHP 5.2 的时代吧！
