Download as PDF, PPTX
More Related Content
![[NDC17] Unreal.js - 자바스크립트로 쉽고 빠른 UE4 개발하기](https://cdn.slidesharecdn.com/ss_thumbnails/wjkqukgsqgm2vger5dnt-signature-2cf736e9b897e2aaaa6315f9d31d6951ba19fae7560fe278cefb4644ac0753c6-poli-170428114140-thumbnail.jpg?width=640&height=640&fit=bounds)
![[IGC 2016] 넷게임즈 김영희 - Unreal4를 사용해 모바일 프로젝트 제작하기](https://cdn.slidesharecdn.com/ss_thumbnails/igcppt-161008143730-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to なぜ、PHPのmbstring.func_overloadをdeprecatedにするのに5年かかったのか? - 慢心、環境の違い
なぜ、PHPのmbstring.func_overloadをdeprecatedにするのに5年かかったのか? - 慢心、環境の違い
- 1. なぜ、 PHP のmbstring.func_overload を deprecated にするのに 5 年 かかったのか？ - 慢心、環境の違い Y8 2017 spring in Shibuya sasezaki May 27, 2017
- 2. 2 目次 ● 自己紹介 ● PHP のこれまで ● PHP の仕組みと 拡張モジュール ● PHP と 文字列 ● mbstring.func_overload の機能について ● 非推奨提案するに至った経緯 / 提案以降の話 ● 5 年かけたことについての反省点 ● "mbstring.func_overload" と同じ事態を避けるには ● まとめ ● ... おまけの話 ( 例えば文字列を避ける、 7.2 での他の deprecated)
- 3. 3 自己紹介 はじめまして！ sasezaki です。 私がmbstring.func_overload につい て deprecated を表示するようにしろ ! と bugs.php.net に issue レポート (#65785) した人です。
- 4. 4 過去の主な Talk 2009 /PHP勉強会 PHP カンファレンス 2011 PHP カンファレンス福岡 2016
- 5.
- 6.
- 7.
- 8. 8 私は 「俺 ホントはPHP のこと、ちっとも 分かってあげてやれてなかったんだ！」 というのを 10 年ぐらい続けてます。
- 9.
- 10.
- 11. 11 PHP: Hypertext Preprocessor としてよく聞く話 ・LAMP (Linux, Apache, MySQL, P＊＊ ) の P として普及 ・ C によく似た文法。グルー言語としてみなされることもある ・ 非常に多くの機能( 拡張 / 関数・クラス ) が標準で 用意されている。
- 12.
- 13. 13 PHP の普及期 .php3 拡張子？ ZendEngine 1 デフォルトでは、 register_globals をオフに - 4.2 stream (I/O抽象化レイヤー ) の導入 - 4.3 1999 2003~
- 14. 14 PHP 3 や4 の初期 、みんな mbstring を使っていたかというと・・・ ➔ PHP 版の jcode もありましたが・・・ ➔ ※ PHP 3の頃は、前身として I18n Package というものだったようです。 (ext/mbstring/README_PHP3-i18n-ja) 1999 2003~
- 15. 15 PHP 5移行期 ● 日本にとどまらず、勉強会やカンファレンスが活発に ● “ フルスタックフレームワーク”ブームもありオブジェクト 指向が意識されるように なぜフルスタックを重宝した? (依存性 ? PHP 4/5バージョンの差異への対応 ?) ● PHP 5.3リリースまで間が空く 2004 2008~
- 16. 16 さよなら PHP 6 ● 5.3リリース ● register_globals , safe_mode, magic_quotes_gpc の非 推奨化 (E_DEPRECATED エラー ) ● バイナリセーフではない関数 (ereg, split)の非推奨化 ● GitHub の浸透も相まって ライブラリなど PHP でも開発が活 発に / CIの SaaS 台頭 2009 2012~
- 17. 17 ~~ PHP 5.6そしてPHP 7.0, 7.1~ ● 5.5 - preg_replace()の /e 修飾子 (eval) が非推奨に ● 5.6 - iconvおよび mbstring の、エンコーディングに関する オプションが非推奨に ● PHP 7.0 リリース ● スカラー型宣言 / 戻り値の型宣言 の導入 ● AST 導入 2013 2017~
- 18. 18 PHP 7.2~ ● 7.2 ● 非推奨の追加 – $php_errormsg,create_function(), mbstring.func_overload など ● 8.0 ● 2020 年 ? ● JIT ? 2017~ https://wiki.php.net/todo/php72#timetable
- 19.
- 20. 20 PHP の 仕組みと 拡張モジュール
- 21.
- 22.
- 23.
- 24. 24 コア拡張 ● ストリーム (4.3 にて登場) ● Phar (5.3から組み込み ) ● SPL (5.3から組み込み ) ・・・など 今となっては、当然存在するでしょ ! という機能も、過去にはビルド時に外せた 「これらは実際のところ拡張ではありません。 PHP の コアに組み込まれており、 コンパイルオプションで 無効にすることはできません。」 http://php.net/extensions.membership
- 25. 25 バンドルされている拡張 ● iconv ● マルチバイト文字列 (mbstring) ● intl ・・・など 「これらの拡張は PHPにバンドルされています。」 http://php.net/extensions.membership
- 26. 26 外部拡張 ● 各 DB 向けドライバ(MySQLi など ) ● Gettext ● DOM ● cURL ・・・など 「これらの拡張は PHP にバンドルされています が、コンパイルするには外部ライブラリが 必要となります。」 http://php.net/extensions.membership
- 27. 27 PECL 拡張 ● V8js ● SPL_Types /DataStructures ● phtreads / 各イベント系 (libevent など ) ● mysqlnd_* 系 ・・・など ここまでが、 php.net にてマニュアルが 閲覧できるものです。 「これらの拡張は » PECL にあります。 また、 外部のライブラリを必要とするかもしれません。」
- 28.
- 29. 29 PHP の しくみ/ 拡張モジュール PHP 自体でのフック・コード解析する余地がある。 開発者と利用者 ( コンポーネント開発者 ) が想定する 環境はコアとバンドルである。
- 30.
- 31. 31 「 PHP では、文字は 1 バイトと同じで す。つまり、 256 個の異なる文字を使用可 能です。 これは、PHP が Unicode をネ イティブにサポートしていないことも意味 します。」 http://php.net/language.types.string
- 32. 32 「 PHP における文字列型は、バイトの配 列と整数値( バッファ長 ) で実装されてい ます。 バイト列を文字列に変換する方法に ついては何の情報も持っておらず、完全に プログラマ任せとなっています。」 http://php.net/language.types.string
- 33.
- 34.
- 35.
- 36.
- 37. 37 ... あなたの PHPで書かれたプログラム ソースではバイナリ操作って行います？ ( バイナリ操作のために文字列関数使ってますか？ )
- 38. 38 PHP と バイナリ操作と・・ ● 画像処理(GD, ImageMagick) ● ファイル判定 (finfo) ● password_hash などの パスワードのハッシュ (5.5) ● random_bytes (PHP 7.0)
- 39. 39 「けど、けど、文字 ( テキスト) とバイナリ を分 けないと不便じゃん！」
- 40. 40 もしかして、 PHP 6の話 ですか？ https://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
- 41.
- 42. 42 PHP と 文字列 PHPでは低レイヤに関わる機能の多くを提供し ている。 PHP で 文字エンコーディングに関わる操作を行 うときは、専用のモジュールが必要となる。
- 43.
- 44. 44 「 PHP アプリケーションの多くは、英語 等のシングルバイトの言語用に設計されて おり、日本語を含むマルチバイト文字列を 扱う場合には問題を生じる場合がありま す。 substr() 等の PHP の文字列関数の 多くは、 マルチバイト文字列に対応してい ません。」 php.net/mbstring.overload
- 45.
- 46. 46 「 mbstring では、対応するマルチバイト文字対 応版の関数で既存の PHP 関数を オーバーロード する機能をサポートします。関数のオーバーロード を行うと、例えば substr() を PHP スクリプトで コールした場合に、 mb_substr() が代わりにコー ルされるようになります。 これにより、マルチバ イト文字に対応しないアプリケーションの移植が容 易となります。」 php.net/mbstring.overload
- 47.
- 48.
- 49. 49 動作例 mbstring.internal_encoding = UTF-8 mbstring.func_overload= 2 php.ini sample.php <?= strlen(" あ "); // 1
- 50.
- 51.
- 52. 52 mbstring.func_overload はマルチバイトを考慮できてな いアプリケーションへの解決案だった。 バイナリと文字に違いがない PHPにとっては、影響の 高い機構だった。 mbstring.func_overload とは
- 53.
- 54. 54 2012 年 ● Zend Framework2の開発がスタート ● Db などのいくつかのコンポーネントのアーキテクチャ は書きなおされました。が、あくまでベースは ZF1 。
- 55. 55 当時の私は、こういう憤りをもってました。 「メジャーバージョンアップに合わせて git に移行し たけど、(1. 系からの ) 枝分かれ以降の修正が取り込まれ てないじゃん。ずこ！」
- 56. 56 プルリク！マージ ! 貢献! 圧倒的成長 !
- 57.
- 58. 58 Zend Framework の開発者ML 2012 年 4 月
- 59. 59 zf1 にて、各コンポーネントごとで PHP環境の 差分対応のために横展開的な修正があったことから、 ユーティリティコンポーネント (ZendStdlib) の開発気風が高まり、その一環で マルチバイト対応の点から、 StringUtils の提案が行われます。
- 60.
- 61. 61 メイン開発者の一人 Ben Scholzenの投稿 http://zend-framework-community.634137.n4.nabble.com/Environment-amp-StringUtils-td4559272.html
- 62.
- 63. 63 かくして、 ZF 2では mbstring.func_overloadを サポートしない方向へ 2012 年 4 月
- 64.
- 65. 65 CakePHP や Symfony、 PEAR の ライブラリでもフラグによる分岐が あることを踏まえて、廃止の提案
- 66.
- 67. 67 大垣さんが deprecated の提案をinternals に投稿 ※ internals とは、 PHP のコア開発についてのメインの ML です。 http://news.php.net/php.internals
- 68. 68 その時 (2012 年4 月 ) の反応 ＞ 特になし！ ＜
- 69. 69 ... もちろん この2012年 4 月の時点で 「 mbstring.func_overload やめた方が 良くない？」 が PHP 利用者に伝わる訳ではなく。。
- 70. 70 2012 年 5月 https://github.com/reactphp/react/pull/27
- 71. 71 ReactPHP での mbstring.func_overload が ONのときをサポートしようとする Pull Request 2012 年 5 月
- 72.
- 73. 73 igorw のレスポンス 「 mbstring.func_overloadの振る舞いは register_globals や magic quotes への 汚いハックを思い出させる」
- 74.
- 75.
- 76. 76 2013 年 10月 「ユニコードについてのスライド up しました」、 という PHP 開発者のツイート https://twitter.com/auroraeosrose/status/388380154713489409
- 77. 77 `Intl doesn't supportfunction “overloading”`
- 78. 78 Nikita が 反応 「func_overload は ASAP な drop 対象でしょ」
- 79. 79 僕「その件なんですけど、 bugs にレポート してまして・・」 Nikita「 intenals に投稿して」
- 80.
- 81. 81 ~~ けど、そのまま時は流れ ~~ PHP7の開発も佳境に入り
- 82. 82 Nikita の deprecationの提案 2015 年 3 月
- 83.
- 84.
- 85. 85 2016 年 2月 7.1 に向け Deprecation の RFC 提案が出され http://news.php.net/php.internals/91265
- 86. 86 2016 年 11月 RFC は 7.2 向けの Deprecations に http://news.php.net/php.internals/96993
- 87. 87 2016 年 11月 非推奨の一つとして、 mbstring.func_overload が リストに上がる https://wiki.php.net/rfc/deprecations_php_7_2
- 88. 88 賛成多数で可決 2017 年 1月 https://wiki.php.net/rfc/deprecations_php_7_2
- 89.
- 90. 90 2016 年 12月 ・・ twig ではしれっと削除されてる https://github.com/twigphp/Twig/commit/b09faf8
- 91. 91 非推奨と提案するに至った経緯 / 各開発者の反応 PHP 利用者( 主にライブラリ作成者 ) は、 PHP が標準 で用意しているがために mbstring.func_overload をサ ポートしようとしていた。 PHP 自体が用意している機能でも見直すことが必要。
- 92.
- 93. 93 Zend Framework 2での ML でのやりとり、および日本人メ ンテナーへの報告 (2012 年 ) から internals での投票可決と master への反映まで 5 年の月日が経過していた。 ※ PHP 7.2 はまだリリースはされていません。 ➔なぜ 5 年かけてしまったのか？ ➔5 年の歳月のうち取れた行動はなかったのか？
- 94.
- 95. 95 ● レポートは一度どこかに投稿すれば終わりという訳で はない ● 動きがなかったら、再度自分からアクションを起こ すしかない ➔internals や bugs.php.netへの登録は もっと早めにできたはず 取れるべきアクションを取らなかった 慢心
- 96. 96 取れるべきアクションを取らなかった 慢心 ● マニュアルに注意書きを載せることも可能だった ● 実は、 php.gr.jpへの投稿時に注意書きも載せた方がいい ですね。という話はあった。 – コミット権がないことに、人任せになっていた。 – マニュアルの警告追記も用意してマージ依頼までもでき たはず。 ● 警告の理由を、皆が納得できるように事細かく書かな ればという思いこみもあった。という逃げ
- 97. 97 環境の違い を否定 できてなかった後悔 ● 環境の違いを否定する環境づくり ● ライブラリ導入時のチェックを強化すべきだったのでは –例 ) mbstring.func_overloadがオンの時にコンポーネント をインストールさせない ● 周知・啓蒙が足りなかった ?
- 98.
- 99.
- 100.