ログイン



Tags » ‘PHP6’

PHP6 (5.4?) の新機能

12月 29th, 2010 by

PHP5.4を知らない人は要チェック。いやPHP6.0か?

PHP5.4で実装される予定の新機能がわかりやすく解説されています。

新しくサポートされるもの。

  • dereferencing (参照から実体を取り出す機能 getValues()[1] のような記法を使えます)
  • 型チェック機能
  • 多重継承の実現(trait)
  • キーバリューシステム(KVS)のTokyoCabinetをサポート
  • サポートが打ち切られるもの。

  • register_globals
  • Safe mode
  • 詳細は、元記事をご覧ください。

    PHP6の文字コード実装、UTF-3に決定

    4月 3rd, 2010 by

    PHP6の文字コード実装、UTF-3に決定

    その名もUTF-3。仕様は以下のとおりです。

    * わずか3bitで表現可能
    * テキストで表現する時には、アルファベットの’R’,’A’,’I’,’N’,’F’,’U’,’C’,’K’を使用

    使用決定の日に雨が降っていたのが決定打となった模様です。

    エイプリルネタでこんな記事が書かれていました。UTF-16化がキャンセルになったPHP6ですが、開発は再スタートを切れたのでしょうか?50%を超えるWebサイトがUTF-8で記述されている現状を考えれば、UTF-8を採択する可能性はあっても、再びUTF-16で開発を進める可能性はなさそうです。次期バージョンの文字コードがどうなるかはともかく、今後もPHPの開発が継続されることを願います。

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

    次期PHPのバージョン番号は不明

    3月 22nd, 2010 by

    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 系に巻き戻し

    3月 22nd, 2010 by

    開発中の 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がリリースされるのはいつのことやら。