ログイン



Future of PHP6

月曜日, 3月 22nd, 2010 by

Future of PHP 6

PHP6の開発方針についての記事があったので、ざっくり訳してみた。

Yesterday was a quite thrilling day for the PHP development team and led to some imprecise news articles so let’s take a look at what happened: Over the last months many of the core contributors agreed that the current approach to bring Unicode into PHP’s engine wasn’t the right approach and a good thing would be to rethink it from the start. By a provocative move of one contributor the stalled situation got some more movement and Rasmus declared the current implementation to be discontinued to restart

昨日は、PHPの開発チームにとってスリリングな1日だった。不正確な記事も書かれてしまったようなので、何が起こったのか確認してみよう。過去数カ月の議論を経て、PHPの中心開発メンバーの多くは、UnicodeをPHPのエンジンに持ち込むことは正しい選択ではないという意見で一致した。そして、Rasmus(PHPの最初のバージョンの開発者)は、現在の実装作業を中断し、(5.3のブランチから)再出発することを宣言した。

The past
過去

When the foundation of what should have become PHP 6 was created a decision was made to use UTF-16 as internal encoding for “everything” inside the engine. The choice for UTF-16 was made due to the fact that PHP 6 would use the ICU library which is focused on offering UTF-16 string functions. By using UTF-16 as default encoding we’d have to convert the script code and all data passed from or to the script (request data, database results, output, …) from another encoding, usually UTF-8, to UTF-16 or back. The need for conversion doesn’t only require CPU time and more memory (a UTF-16 string takes double memory of a UTF-8 string in many cases) but makes the implementation rather complex as we always have to figure out which encoding was the right one for a given situation. From the userspace point of view the implementation brought some backwards compatibility breaks which would require manual review of the code. These all are pains for a very small gain for many users where many would be happy about a tighter integration of some mbstring-like functionality. This all led to a situation for many contributors not willing to use “trunk” as their main development tree but either develop using the stable 5.2/5.3 trees or refuse to do development at all.

PHP6では、文字列の処理にICUライブラリを利用するのだが、このライブラリはUTF-16向けの機能に焦点が合てられている。そのため、PHP6のコアエンジンはUTF-16で開発を進めたのだが、そのことが多くの不都合を生み出した。UTF-8からUTF-16への変換、もしくはその逆の変換を頻繁に行わなければならず、CPUやメモリに負荷をかけるだけではなく、実装の煩雑さをももたらしてしまった。PHP利用者にとっても、後方互換性が確保できないという問題があり、既存のソースコードを人の手で確認する必要性が発生していしまった。そのため、多くの貢献者(PHP開発を行っている人)は、開発版のPHP(PHP6となる予定だった開発Trunk)ではなく、PHP5.2やPHP5.3を使うようになってしまった。

The present
現在

Yesterday the stagnation created by the situation has been resolved and it was decided that our trunk in svn will be based on 5.3 and we’ll merge features from the old trunk and new features there so that 5.3 will be a true stable branch. The EOL for 5.2 has not yet been defined but I suggest you to really migrate over to 5.3, which usually can be done with very little work, as soon as possible.

昨日、停滞は打ち破られ、PHP5.3を元にSubversionのTrunkを作ることに決定した。PHP5.3を安定版として維持するために、旧Trunk(6に向けて開発されていたTrunk)で実装されていた機能は(5.3ではなく、)新しいTrunkに組み込まれる。5.2のメンテナンス期限はまだ決定していないが、もし5.2上を使っているのであれば、早急に5.3に以降することを推奨する。5.2から5.3への以降には多くの手間は掛からないはずだ。

The future

Right now we’re starting different discussions to see what kind of Unicode support we really want. Many contributors react positive on a proposed “string class” which wraps string operations in Unicode and binary forms without going deep in the engine. In my opinion such an approach might also be a way to solve some of the often criticized inconsistencies in PHP’s string APIs without the need to break old code. (new code uses the new class, old code the old functions) But that idea is far from a proper proposal or even the implementation, current status is about refocusing the development and get the requirement and design discussions going. By that it’s a bit early to decide whether the next version of PHP will be called PHP 5.4, PHP 6 or maybe even PHP 7.

どのようなUnicode対応が実際に求められているのかについての議論が始められようとしている。エンジンの深い部分には手をつけず、”string”クラスを使う手法に前向きの反応を示している開発者が多い。私の意見としては、そのような手法は、過去のコードとの互換性を失わずに(過去のコードは既存のAPIを、新しいコードはstringクラスを使えば良い)、PHPの文字列APIの一貫性の無さを解消するための方法としてあり得ると思う。だが、このアイディアは、真っ当な提案、ましてや実装とは程遠いものであるし、現時点では、要求や設計のぎりんに集中すべきである。まだ、次のバージョンが、PHP5.4なのか、PHP6なのか、それとも、PHP7なのかを決定するには少々早すぎる。

PHP is alive and kicking!
PHPは、生きている。そして、活気にみち溢れている!

Leave a Reply