アカウント名:
パスワード:
5.4の新機能の為に移りましょうよ
traitがとても便利似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ？(フレームの元？)trait型とかは使えないけど、まあ、PHPだしabstractメソッドとかは持てるし色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植したprivateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意(useで変更もできるけど面倒なので)
後Arrayの砂糖さんが地味に便利 Array() ⇒ [] function (Array $arg = []){…}とか、 private $m_option = [];とか
パフォーマンスも上がってる処理にもよるけど10%～20%とかAPCを使ってる環境だと何故かもっと上がるっぽい測っていないけど客からパフォーマンスチューニングしてくれた？とか聞かれる位、目に見えて速度上がったパフォーマンスチューニングで10%～20%とかあげるのは(元がダメダメなコードとかでなければ)どれだけ大変かと
確かに変更点は多いけど、普通に5.3用に書かれたコードなら大体何もしなくても動く動かなくても殆どのケースでちょっと修正程度の事が殆ど古いライブラリで警告やエラーが出る事があるので、そこだけチェックして問題なさそうならさっさと5.4にするのがお勧め
> 動かなくても殆どのケースでちょっと修正程度の事が殆どこの「ちょっと修正」をしたくないからみんな移らないんだよね。
新機能やSyntax Sugerとかを使うから、次のバージョンアップの際にさっそく仕様変更されて、また書き直す羽目になるんですよね。。そういう思いを何度もすると人は学習して、段々とガチガチのコア機能しか使わなくなってくるという
しかもPHPの場合は「ちょっと修正」しなければならない場所を検出するのが、超めんどくさい。そこが最大の障害と言ってもいいくらいに。
まず「コンパイル」がないから、コンパイル時のエラーでは変更点やバグを検出できないし、実行時エラーも一度実行しただけでは出るとは限らず、全パスの全ての組み合わせを網羅的に実行してようやくエラーが出る有様。
さらに酷い時は関数や演算子の動作が変更されていて、実行したら結果は変われど、実行時エラーが出ずにすんなり動いてしまうことも。
その結果、変更する部分が仮に本当に少しだけだったとしても、新バージョンへの移植とデバッグにかかるコストが膨大になる。
PHP界隈には自動テストの習慣ってないんでしょうか？それとも、最先端のWeb開発ではテストを自動化するという流れはもう廃れてしまったのでしょうか？
ないわけではないけれど、日本だと、「人月単価が安いから ≒ 低スキル技術者を使えるから」がPHPを採用する最大の理由だから。ユニットテストだなんて、そんな『高度なスキル』を駆使できる会社の方が珍しいかも。＃そういう意味ではPHPは「最先端のWeb開発」じゃなくて、「時代遅れのWeb開発」なのです。
そういう職場ではMVCフレームワークどころか、共通モジュールの切り分けさえせずに、ガチガチに結合した単一のPHPファイルで書く人も多い。結果としてテスト不可能なコードが量産されるので、ユニットテストどころの騒ぎでは無い。
かといってPHPではフレームワークを使うと、今度はそのフレームワークが「フレームワーク Ver1はPHP5.0から5.2.xまでしか動きません。
自分が作ったコード部分ならまだしも、他者が作ったライブラリやフレームワークについては、ユニットテストがあろうとなかろうと、変更する部分を検出することは困難。
かりに判明しても、ライブラリがPHPの新しいバージョン用には提供されてなくて、差し替えようにも代替となるライブラリが存在しなくて、移行は断念せざるをえなかったり。運良く代替ライブラリが見つかっても、互換ではないために差し替えのコストがかなり高く付いたり。
ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？言語のバージョンアップから検証が終わるまでのタイムラグはあるかもしれませんが、だからと言って利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。
＞ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？理想としてはそうだと思う。でもPHP界隈における現実は違う。
開発／サポートが打ち切られてPHP新バージョン用には提供されてなかったり、新しいバージョンで動くライブラリはあるけど互換性がありませんだったりは珍しくない。ライブラリの開発者だって、次々と互換性のない変更の入るPHP言語にウンザリしてるんでしょう。
結果として結局は互換性の無いライブラリ間の移植作業や、ライブラリの独自カスタマイズが必要になる。
＞利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。まったくその通りだと思います。
それがPHPのバージョン間の移行コストが激しく高くなる原因の一つですね。#だからPHPなんて糞言語を採用するなとあれほど……。 orz
> 古いライブラリで警告やエラーが出る事があるので、そこだけチェックして問題なさそうならさっさと5.4にするのがお勧め
趣味でPHP使ってるならこんないい加減な判断でも何も問題ありませんが，業務だと有り得ない話ですね．
うん、おっしゃるとおり。でもサポートが終了した処理系を使うのも業務ではありえない・・・と思うんだが、往々にしてありえるのが困るんだよな。
PHP は民間企業が延長サポートサービスしてたりするよ。
アプリの工数100万なんて真面目にプロジェクト管理すると何もしないのと同じようなもんだから、その程度の金でセキュリティ対応できるなら安いという判断はありかもね。
まぁ根本対応はPHPのライフサイクルか、互換性のどちらかをまともにする必要があるわけですが。
PHPが使われてるような業界では、100万円ははした金とは言えないと思う。
まともなプログラマを採用する気もない会社が採用する技術だもの。
なんで有り得るんだろう？困ったらどうする？その辺を語らなきゃ、抽象的で無意味なグチですな。
# 俺の周辺では無いのは救いだ
あり得るのは、移行コストが高すぎるから。特にPHP。
困るのは、たとえば処理系のバグや脆弱性が見つかった時に、コミュニティに頼ることができず自分で修正するしか無いこと。それを修正できる保証も無いし、仮にできたとしても時間も金もかかる。
実際には移行するだけの人も金もないから使ってるんだし、おそらく修正は無理。綱渡り状態だよ。
それを上司や経営者が理解してないのが最大の問題だな。
別ACだけど、言語に対するサポートなんて飾りじゃないの？PHP本体がどれだけバグってようが、要は自分とこのユースケースでがっちり試験してその範囲だけでの動作保証を自ら行いさえすれば、言語のバージョンなんて上げなくてよくね？
OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあある意味バグも仕様なわけで。自分らで回避して作りこめばそれまでだよね。
> OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。ん？PHPは不特定ユーザからの入力を受けますよ？その中には、不具合を誘発する入力があるかもしれません。
> サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあサポート切れたソフトに対してバグ探しをしてくれる人がいればいいですけどね。
逆です。PHP終了のお知らせと解釈した方がいいでしょう。これまで使っていたところが、バージョンアップに反応していないんだから。
バージョンアップに反応してないのは、作るだけ作ったけどメンテナンス体制が整えられてないサイトが多数存在するのではないでしょうか。PHPで作られているCMSも多いので、CMSを使ったコンテンツ作成はできるけどPHPはよくわからんっていう人は多い気がします。
いや、もうPHPから別の環境に移行すれば？
中小向けのWeb制作が触るサーバだと、Perlなんて5.8系がデフォです。
いろいろ触れるところなら、Perlbrewなり何なりで自力で何とかなるんですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
さっさと移行するのがお勧めです(オフとぴ) (スコア:3, 参考になる)
5.4の新機能の為に移りましょうよ
traitがとても便利
似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ？(フレームの元？)
trait型とかは使えないけど、まあ、PHPだし
abstractメソッドとかは持てるし
色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり
嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、
DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植した
privateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意
(useで変更もできるけど面倒なので)
後Arrayの砂糖さんが地味に便利
Array() ⇒ []
function (Array $arg = []){…}とか、
private $m_option = [];とか
パフォーマンスも上がってる
処理にもよるけど10%～20%とか
APCを使ってる環境だと何故かもっと上がるっぽい
測っていないけど客からパフォーマンスチューニングしてくれた？とか聞かれる位、目に見えて速度上がった
パフォーマンスチューニングで10%～20%とかあげるのは(元がダメダメなコードとかでなければ)どれだけ大変かと
確かに変更点は多いけど、普通に5.3用に書かれたコードなら大体何もしなくても動く
動かなくても殆どのケースでちょっと修正程度の事が殆ど
古いライブラリで警告やエラーが出る事があるので、そこだけチェックして問題なさそうならさっさと5.4にするのがお勧め
Re:さっさと移行するのがお勧めです(オフとぴ) (スコア:1)
> 動かなくても殆どのケースでちょっと修正程度の事が殆ど
この「ちょっと修正」をしたくないからみんな移らないんだよね。
Re: (スコア:0)
新機能やSyntax Sugerとかを使うから、次のバージョンアップの際にさっそく仕様変更されて、また書き直す羽目になるんですよね。。
そういう思いを何度もすると人は学習して、段々とガチガチのコア機能しか使わなくなってくるという
Re: (スコア:0)
しかもPHPの場合は「ちょっと修正」しなければならない場所を検出するのが、
超めんどくさい。そこが最大の障害と言ってもいいくらいに。
まず「コンパイル」がないから、コンパイル時のエラーでは変更点やバグを検出できないし、
実行時エラーも一度実行しただけでは出るとは限らず、全パスの全ての組み合わせを
網羅的に実行してようやくエラーが出る有様。
さらに酷い時は関数や演算子の動作が変更されていて、実行したら結果は
変われど、実行時エラーが出ずにすんなり動いてしまうことも。
その結果、変更する部分が仮に本当に少しだけだったとしても、新バージョンへの
移植とデバッグにかかるコストが膨大になる。
Re: (スコア:0)
PHP界隈には自動テストの習慣ってないんでしょうか？
それとも、最先端のWeb開発ではテストを自動化するという流れはもう廃れてしまったのでしょうか？
Re: (スコア:0)
ないわけではないけれど、日本だと、
「人月単価が安いから ≒ 低スキル技術者を使えるから」
がPHPを採用する最大の理由だから。
ユニットテストだなんて、そんな『高度なスキル』を駆使できる会社の方が珍しいかも。
＃そういう意味ではPHPは「最先端のWeb開発」じゃなくて、「時代遅れのWeb開発」なのです。
そういう職場ではMVCフレームワークどころか、共通モジュールの切り分けさえ
せずに、ガチガチに結合した単一のPHPファイルで書く人も多い。結果として
テスト不可能なコードが量産されるので、ユニットテストどころの騒ぎでは無い。
かといってPHPではフレームワークを使うと、今度はそのフレームワークが
「フレームワーク Ver1はPHP5.0から5.2.xまでしか動きません。
Re: (スコア:0)
自分が作ったコード部分ならまだしも、他者が作ったライブラリやフレームワークについては、
ユニットテストがあろうとなかろうと、変更する部分を検出することは困難。
かりに判明しても、ライブラリがPHPの新しいバージョン用には提供されてなくて、差し替えようにも
代替となるライブラリが存在しなくて、移行は断念せざるをえなかったり。運良く代替ライブラリが
見つかっても、互換ではないために差し替えのコストがかなり高く付いたり。
Re: (スコア:0)
ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？
言語のバージョンアップから検証が終わるまでのタイムラグはあるかもしれませんが、だからと言って利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。
Re: (スコア:0)
＞ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？
理想としてはそうだと思う。
でもPHP界隈における現実は違う。
開発／サポートが打ち切られてPHP新バージョン用には提供されてなかったり、
新しいバージョンで動くライブラリはあるけど互換性がありませんだったりは珍しくない。
ライブラリの開発者だって、次々と互換性のない変更の入るPHP言語にウンザリしてるんでしょう。
結果として結局は互換性の無いライブラリ間の移植作業や、
ライブラリの独自カスタマイズが必要になる。
＞利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。
まったくその通りだと思います。
それがPHPのバージョン間の移行コストが激しく高くなる原因の一つですね。
#だからPHPなんて糞言語を採用するなとあれほど……。 orz
Re: (スコア:0)
> 古いライブラリで警告やエラーが出る事があるので、そこだけチェックして問題なさそうならさっさと5.4にするのがお勧め
趣味でPHP使ってるならこんないい加減な判断でも何も問題ありませんが，
業務だと有り得ない話ですね．
Re:さっさと移行するのがお勧めです(オフとぴ) (スコア:1)
うん、おっしゃるとおり。
でもサポートが終了した処理系を使うのも業務ではありえない
・・・と思うんだが、往々にしてありえるのが困るんだよな。
Re:さっさと移行するのがお勧めです(オフとぴ) (スコア:1)
PHP は民間企業が延長サポートサービスしてたりするよ。
アプリの工数100万なんて真面目にプロジェクト管理すると何もしないのと同じようなもんだから、
その程度の金でセキュリティ対応できるなら安いという判断はありかもね。
まぁ根本対応はPHPのライフサイクルか、互換性のどちらかをまともにする必要があるわけですが。
[Q][W][E][R][T][Y]
Re: (スコア:0)
PHPが使われてるような業界では、100万円ははした金とは言えないと思う。
まともなプログラマを採用する気もない会社が採用する技術だもの。
Re: (スコア:0)
なんで有り得るんだろう？
困ったらどうする？
その辺を語らなきゃ、抽象的で無意味なグチですな。
# 俺の周辺では無いのは救いだ
Re:さっさと移行するのがお勧めです(オフとぴ) (スコア:1)
あり得るのは、移行コストが高すぎるから。特にPHP。
困るのは、たとえば処理系のバグや脆弱性が見つかった時に、コミュニティに頼ることが
できず自分で修正するしか無いこと。それを修正できる保証も無いし、仮にできたとしても
時間も金もかかる。
実際には移行するだけの人も金もないから使ってるんだし、おそらく修正は無理。
綱渡り状態だよ。
それを上司や経営者が理解してないのが最大の問題だな。
Re: (スコア:0)
別ACだけど、
言語に対するサポートなんて飾りじゃないの？
PHP本体がどれだけバグってようが、要は自分とこのユースケースでがっちり試験して
その範囲だけでの動作保証を自ら行いさえすれば、言語のバージョンなんて上げなくてよくね？
OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。
サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあ
ある意味バグも仕様なわけで。自分らで回避して作りこめばそれまでだよね。
Re: (スコア:0)
> OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。
ん？PHPは不特定ユーザからの入力を受けますよ？
その中には、不具合を誘発する入力があるかもしれません。
> サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあ
サポート切れたソフトに対してバグ探しをしてくれる人がいればいいですけどね。
Re: (スコア:0)
Re: (スコア:0)
逆です。
PHP終了のお知らせと解釈した方がいいでしょう。
これまで使っていたところが、バージョンアップに反応していないんだから。
Re: (スコア:0)
バージョンアップに反応してないのは、作るだけ作ったけどメンテナンス体制が整えられてないサイトが多数存在するのではないでしょうか。PHPで作られているCMSも多いので、CMSを使ったコンテンツ作成はできるけどPHPはよくわからんっていう人は多い気がします。
Re: (スコア:0)
いや、もうPHPから別の環境に移行すれば？
Re: (スコア:0)
中小向けのWeb制作が触るサーバだと、Perlなんて5.8系がデフォです。
いろいろ触れるところなら、Perlbrewなり何なりで自力で何とかなるんですが。