アカウント名:
パスワード:
5.4の新機能の為に移りましょうよ
traitがとても便利似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ？(フレームの元？)trait型とかは使えないけど、まあ、PHPだしabstractメソッドとかは持てるし色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植したprivateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意(useで
> 動かなくても殆どのケースでちょっと修正程度の事が殆どこの「ちょっと修正」をしたくないからみんな移らないんだよね。
しかもPHPの場合は「ちょっと修正」しなければならない場所を検出するのが、超めんどくさい。そこが最大の障害と言ってもいいくらいに。
まず「コンパイル」がないから、コンパイル時のエラーでは変更点やバグを検出できないし、実行時エラーも一度実行しただけでは出るとは限らず、全パスの全ての組み合わせを網羅的に実行してようやくエラーが出る有様。
さらに酷い時は関数や演算子の動作が変更されていて、実行したら結果は変われど、実行時エラーが出ずにすんなり動いてしまうことも。
その結果、変更する部分が仮に本当に少しだけだったとしても、新バージョンへの移植とデバッグにかかるコストが膨大になる。
PHP界隈には自動テストの習慣ってないんでしょうか？それとも、最先端のWeb開発ではテストを自動化するという流れはもう廃れてしまったのでしょうか？
自分が作ったコード部分ならまだしも、他者が作ったライブラリやフレームワークについては、ユニットテストがあろうとなかろうと、変更する部分を検出することは困難。
かりに判明しても、ライブラリがPHPの新しいバージョン用には提供されてなくて、差し替えようにも代替となるライブラリが存在しなくて、移行は断念せざるをえなかったり。運良く代替ライブラリが見つかっても、互換ではないために差し替えのコストがかなり高く付いたり。
ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？言語のバージョンアップから検証が終わるまでのタイムラグはあるかもしれませんが、だからと言って利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。
＞ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？理想としてはそうだと思う。でもPHP界隈における現実は違う。
開発／サポートが打ち切られてPHP新バージョン用には提供されてなかったり、新しいバージョンで動くライブラリはあるけど互換性がありませんだったりは珍しくない。ライブラリの開発者だって、次々と互換性のない変更の入るPHP言語にウンザリしてるんでしょう。
結果として結局は互換性の無いライブラリ間の移植作業や、ライブラリの独自カスタマイズが必要になる。
＞利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。まったくその通りだと思います。
それがPHPのバージョン間の移行コストが激しく高くなる原因の一つですね。#だからPHPなんて糞言語を採用するなとあれほど……。 orz
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
さっさと移行するのがお勧めです(オフとぴ) (スコア:3, 参考になる)
5.4の新機能の為に移りましょうよ
traitがとても便利
似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ？(フレームの元？)
trait型とかは使えないけど、まあ、PHPだし
abstractメソッドとかは持てるし
色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり
嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、
DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植した
privateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意
(useで
Re: (スコア:1)
> 動かなくても殆どのケースでちょっと修正程度の事が殆ど
この「ちょっと修正」をしたくないからみんな移らないんだよね。
Re: (スコア:0)
しかもPHPの場合は「ちょっと修正」しなければならない場所を検出するのが、
超めんどくさい。そこが最大の障害と言ってもいいくらいに。
まず「コンパイル」がないから、コンパイル時のエラーでは変更点やバグを検出できないし、
実行時エラーも一度実行しただけでは出るとは限らず、全パスの全ての組み合わせを
網羅的に実行してようやくエラーが出る有様。
さらに酷い時は関数や演算子の動作が変更されていて、実行したら結果は
変われど、実行時エラーが出ずにすんなり動いてしまうことも。
その結果、変更する部分が仮に本当に少しだけだったとしても、新バージョンへの
移植とデバッグにかかるコストが膨大になる。
Re: (スコア:0)
PHP界隈には自動テストの習慣ってないんでしょうか？
それとも、最先端のWeb開発ではテストを自動化するという流れはもう廃れてしまったのでしょうか？
Re: (スコア:0)
自分が作ったコード部分ならまだしも、他者が作ったライブラリやフレームワークについては、
ユニットテストがあろうとなかろうと、変更する部分を検出することは困難。
かりに判明しても、ライブラリがPHPの新しいバージョン用には提供されてなくて、差し替えようにも
代替となるライブラリが存在しなくて、移行は断念せざるをえなかったり。運良く代替ライブラリが
見つかっても、互換ではないために差し替えのコストがかなり高く付いたり。
Re:さっさと移行するのがお勧めです(オフとぴ) (スコア:0)
ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？
言語のバージョンアップから検証が終わるまでのタイムラグはあるかもしれませんが、だからと言って利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。
Re: (スコア:0)
＞ライブラリやフレームワークについては、それぞれの開発者が検証をするのでは？
理想としてはそうだと思う。
でもPHP界隈における現実は違う。
開発／サポートが打ち切られてPHP新バージョン用には提供されてなかったり、
新しいバージョンで動くライブラリはあるけど互換性がありませんだったりは珍しくない。
ライブラリの開発者だって、次々と互換性のない変更の入るPHP言語にウンザリしてるんでしょう。
結果として結局は互換性の無いライブラリ間の移植作業や、
ライブラリの独自カスタマイズが必要になる。
＞利用されている現場それぞれで個別に検証するのはさすがに無駄過ぎるでしょう。
まったくその通りだと思います。
それがPHPのバージョン間の移行コストが激しく高くなる原因の一つですね。
#だからPHPなんて糞言語を採用するなとあれほど……。 orz