Yaf是我在俩年前写的一个PHP扩展的MVC框架. 开发Yaf的目的是为了解决使用框架带来的性能下降的经典矛盾.
最初要感谢百度的同仁们的信任, 以及当时各位老大的支持, 容许也敢于让我"试错", 才让Yaf顺利的度过了"没人敢用"的阶段, 大量的百度的新的产品基于Yaf开发, 让Yaf的稳定性得到了充分的验证, 也普遍的提高了PHP应用的执行效率.
而现在, Yaf的高性能又一次在微博的应用中得到了证明, 通过迁移框架到Yaf, 和一些其他优化手段, 我们成功的让新版微博的TPS提高了76%之多, 响应时间下降了近一半.
然而, 我也看到, 还有不少同学对Yaf有疑虑, 甚至有质疑, 有人认为"使用C写框架? 那不是回退到写CGI的时代了?", 于是我想我有必要写一篇文章, 详细介绍下我对Yaf的一些理解.
最早的时候, 我记得是去年我刚加入开发组的时候, 神仙同学曾经提过, 问我是否可以考虑为PHP实现yield. 我当时做过尝试, 但是最后发现需要大改zend executor, 而当时的我还没有那么大的魄力(因为我记得当时我的第一个RFC刚刚被拒绝)认为我能说服那么多人接受这个变动, 所以后来就不了了之了.
但, 现在Nikita Popov, 完整的实现了这个RFC: Generators, 并且已经提供了一个可用的实现, 目前这个RFC在投票阶段, 投票形式也比较乐观, 所以如果不出大问题, PHP5.5将会引入这一新特性.
我就这里为大家简单介绍下, 这个新特性.
缘起最近的一个Feature Request: #62961
早在PHP5.2.0开始, Data URL Scheme(RFC:2397)就已经被PHP的Stream wrapper支持了.
基本上所有的对文件操作的API, 都迁移到的了PHP stream上, 所以, 绝大部分对文件操作的API都是支持Data URL的.
今天这个文章, 就是再次给大家提个醒, 当某个API需要操作对象是文件的时候, 我们其实是可以采用Data URL让他接受一个文件内容字符串的.
最近, 我提交的关于finally的RFC:Supports finally keyword已经提交到了PHP主干, 今天就给大家介绍一下这个新特性的背景, 和使用方法.
关于这个特性的需求, 最早是在2005年提出来的: FR #32100, 但一直没有人去实现它. 上个月又有人提出来, 我就是抱着试试的态度去实现了一下, 因为有人告诉我, 一直没有实现, 有一个原因是因为很难实现(或许对于一个码农来说, 喜欢挑战难题, 是天性, 呵呵)..
关于让"PHP的编译和执行分离"这个问题, 一直有人提, 也一直有人尝试. 提的人认为编译执行分离以后, 可以得到性能提升, 可以做代码保护等.
我本身并不是对这个特性很感冒, 因为这里面存在一个投入产出比. 让我来给大家解释一下, 然而不管怎么样, 在最后我会给大家提供一种方案来实现这个功能.
首先, 这篇文章不是对@左耳朵耗子的C++的坑真的多吗?一文的反驳, 我只是在我的理解角度说一下我对语言选择的一些感悟.
关于C和C++的争论, 由来已久, 从当年Linus攻击C++是恐怖的语言的时候, 就一直没有停歇, 而就我自己来说, 我对C++的掌握还远远不够, 所以没有能力来从语言设计角度来对比(我在最初, 也尝试学过C++, 用过C++, 但后来发现, 我学不好, 用不好, 就放弃了). 所以我尽量避免在这个方面说错话.