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は、生きている。そして、活気にみち溢れている！

PHP6開発 UTF-16化を断念、5.3へロールバック

PHPの次期メジャーバージョンはPHP6になるとみられてきたが、問題を打破するために開発ブランチを5.3ベースへ巻き戻すという対処が実施された。 Rasmus Lerdorf氏がphp.internals: PHP 6においてPHP6 Unicodeの実装が失敗したことを伝えている。PHP6ではエンジン内部の処理がUTF-16に統一される計画になっていたものの、関係者からはこの方針は間違っているのではないかという指摘もあった。今回実装が行き詰まったことで、PHPはUnicodeに対して新しいアプローチをとることになる。

結局のところ、UTF-16に統一すると理想を唱えたところで、「実装」がついてこなければ意味がないということですね。

次のメジャーバージョンがPHP 5.4になるのかPHP 6になるのか、またはPHP 7になるのかはまったく未定。

PHP7というのは流石にないと思いますが、PHP5.4は普通にありそうですね。

開発中の PHP 6、UTF-16 化に失敗。開発ブランチも 5.3 系に巻き戻し

ある Anonymous Coward 曰く、

PHP の次期メジャーバージョンと見られている PHP6 では、内部的には文字列をすべて UTF-16 で処理するという方針が決定していたのだが、これが頓挫した模様 (マイコミジャーナルの記事) 。

PHP 開発者である Johannes Schlüter 氏による 2010/3/12 付けのブログ記事、”Future of PHP 6″ によれば、数カ月前から PHP のコア開発者の多くから「PHP エンジン内部を Unicode 化するというアプローチは正しくないのでは、最初からやり直したほうがよいのでは」という議論が行われていたらしい。

「処理系内部ではすべての文字を Unicode で処理する」というアプローチは Java や Ruby、Python、Perl などですでに採用されているのだが、PHP の開発者らの結論は「プログラムにおいてすべての入出力時に変換処理を行うのはパフォーマンスの点でよろしくなく、実装も複雑になり、後方互換性もなくなる。いっぽうで多くのユーザーが受ける恩恵は非常に小さい」とのことで、とりあえずは現在行われていた PHP エンジンの UTF-16 化はすべて白紙に戻されるようだ。

PHP6エンジンのUTF-16化が白紙に戻されたとのこと。PHP6がリリースされるのはいつのことやら。