アカウント名:
パスワード:
5.4の新機能の為に移りましょうよ
traitがとても便利似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ?(フレームの元?)trait型とかは使えないけど、まあ、PHPだしabstractメソッドとかは持てるし色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植したprivateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意(useで
> 古いライブラリで警告やエラーが出る事があるので、そこだけチェックして問題なさそうならさっさと5.4にするのがお勧め
趣味でPHP使ってるならこんないい加減な判断でも何も問題ありませんが,業務だと有り得ない話ですね.
うん、おっしゃるとおり。でもサポートが終了した処理系を使うのも業務ではありえない・・・と思うんだが、往々にしてありえるのが困るんだよな。
PHP は民間企業が延長サポートサービスしてたりするよ。
アプリの工数100万なんて真面目にプロジェクト管理すると何もしないのと同じようなもんだから、その程度の金でセキュリティ対応できるなら安いという判断はありかもね。
まぁ根本対応はPHPのライフサイクルか、互換性のどちらかをまともにする必要があるわけですが。
PHPが使われてるような業界では、100万円ははした金とは言えないと思う。
まともなプログラマを採用する気もない会社が採用する技術だもの。
なんで有り得るんだろう?困ったらどうする?その辺を語らなきゃ、抽象的で無意味なグチですな。
# 俺の周辺では無いのは救いだ
あり得るのは、移行コストが高すぎるから。特にPHP。
困るのは、たとえば処理系のバグや脆弱性が見つかった時に、コミュニティに頼ることができず自分で修正するしか無いこと。それを修正できる保証も無いし、仮にできたとしても時間も金もかかる。
実際には移行するだけの人も金もないから使ってるんだし、おそらく修正は無理。綱渡り状態だよ。
それを上司や経営者が理解してないのが最大の問題だな。
別ACだけど、言語に対するサポートなんて飾りじゃないの?PHP本体がどれだけバグってようが、要は自分とこのユースケースでがっちり試験してその範囲だけでの動作保証を自ら行いさえすれば、言語のバージョンなんて上げなくてよくね?
OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあある意味バグも仕様なわけで。自分らで回避して作りこめばそれまでだよね。
> OSとかなら話は別だけど、PHPは実行環境そのものを不特定ユーザに開放してるわけじゃないじゃん。ん?PHPは不特定ユーザからの入力を受けますよ?その中には、不具合を誘発する入力があるかもしれません。
> サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあサポート切れたソフトに対してバグ探しをしてくれる人がいればいいですけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
さっさと移行するのがお勧めです(オフとぴ) (スコア:3, 参考になる)
5.4の新機能の為に移りましょうよ
traitがとても便利
似非多重継承ができるのでオブジェクト指向言語としてなんとか許せるレベルになった感じ?(フレームの元?)
trait型とかは使えないけど、まあ、PHPだし
abstractメソッドとかは持てるし
色々なクラスで使うメソッドをメンバで持たなくていいので記述がすっきり
嬉しすぎてデバッグ系のメソッドまとめたtraitとか、メソッド結果キャッシュするtraitとか、
DB結果編集によく使うメソッドまとめたtraitとかTool系のクラスを沢山traitに移植した
privateフィールド名が被るとエラるのでtraitのprivateフィールドにベタな名前つけない点だけ注意
(useで
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は不特定ユーザからの入力を受けますよ?
その中には、不具合を誘発する入力があるかもしれません。
> サポート切れてバグが放置されてたとしても、そういうバグがあると知ってさえいりゃあ
サポート切れたソフトに対してバグ探しをしてくれる人がいればいいですけどね。