【CSDN 12月26日消息】国际  从1996年开始我便一直使用PHP做开发，并在上个十年里看到了PHP一度的鼎盛期。它实际是web开发的标准之一，每几个月就有或大或小的版本发布来介绍新的特性和bug修补。然而，有时却出现无正式文件的、更改现有代码的修改，而且很多修改没有正式的理由，可能只是PHP的commiter觉得所谓的新方法比旧的好。

       2001年（也许是2002年）的时候，get_object_vars()本来只返回定义的类中的属性值，改为了返回所有对象的属性值，当时是4.2.0 和4.2.1或者 4.1.1和4.1.2之间的变更。几个月之后在线docs中才提到这处更改，但版本发布的时候却只字未提。这在当时对我的项目产生了很坏的影响，而且让我们花费了很长时间去查找原因。

       现在当PHP 5.2.5发布的时候，同样的事情再次发生（点击查看原文，原文作者对此做了详细的解释，包括代码）。

       让我苦恼的不是PHP中出现的这些bug，而是在发生了几次之后这样的事情继续发生着。我们知道有一个PHP QA团队，但我不认为他们的专业水平达到了让语言版本推陈出新的程度。看看他们的页面（http://qa.php.net/），貌似他们不认可PHP 5的存在（首页只提到了PHP 4.4x的发布），更何谈他们解决我上文所说的那些问题。

       而且，PHP没有一个人或者一个小组来掌舵，从而无法保证PHP的品质。Ruby有Matz、 Rails有DHH、Perl有 Larry Wall、Linux有Linus、Python有Guido，脚本语言开发的世界里大多有一个或者几个核心的人物来掌控和影响着语言，PHP却没有。即使在大的方面可以取得一致，但像上文提到的那些细节也仍然是个问题。

       “问题未经公布，不得做任何关于PHP 内核的修改，包括bug和其他问题。”话是这么说，但除非看到最终发布的版本，否则我们很难真正知道PHP在发生什么。当我们看到release notes里的issues列表时，却发现只有部分有bug number。这说明了什么？包括我提到的PHP 5.2.5中的问题，PHP 5.2.5 release notes中也没有issue #，而只是提到“fixing a regression”，如果真的是一个regression，那也应当公开，而且release notes中应当提到公开在什么地方。

       “Associate every commit with an issue number”。理想的状态是，issue number应当公布，从而我们可以在PHP中看到这个问题是如何解决的，而且还应当附带一个.phpt测试来演示这个问题是否真的解决了。但按照PHP的规模来看，距离这个状态还很远很远。

       也许PHP 6会好一些？【呐不喊】

原文链接：http://fosterburgess.com/kimsal/?p=390

个人评价：PHP是比较糟糕的，糟糕在于定位开始模糊了，我们看到ruby是一种纯种脚本语言而rails富于了他的web能力，而php一开始为web而生，但他却忽视了最大的问题构架，导致php在软件工程方面的进步远远落后于其他同类型软件。而随着ruby paython等语言的成功，php也开始准备转型了，但会成功吗？面对数量巨大的老系统，php兼顾老版本的时候，同时也失去了未来，不能不说是非常糟糕的。事实上php不太可能走向ruby的定位，只有重新发布一个新版本去和ruby竞争，而原来的web构架在发布一些官方的mvc之后得到快速提升（个人觉得他应该在内核上集成 mvc的主要部件 这样在效率上就会远远超越他的对手，否则前途难料）