アカウント名:
パスワード:
メソッドの補完が出来る。 ダックタイピングはメソッドから型を逆算するから補完が出来ない。まぁ、やろうと思えば出来るんだろうが、型の候補が複数出てくる、Hackもdartと同じで実際は動的型付けだが、補完がしやすいよう言語仕様的に型が書けるようになる。
問題は、多くのPHPプログラマ及びプロジェクトにPHPを導入するPMがそうした利点を理解できるかどうかですかねぇ。理解できていればそもそもPHPを選択しないでしょうし。
自分の経験した範囲ですが、PHP(しか知らない)プログラマはとにかくエラーが嫌いなように思います。Internal Server Errorで何も表示されないよりも、壊れていてもいいから何か画面が出ていれば安心するというか。なので、静的型チェックを行ってエラーになるよりも、型チェックしなくてログにnoticeを山盛り出していたほうがいいという感じです。なんせ、シンボルチェックすら拒否するような文化ですから。。。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
静的型付けの利点 (スコア:1)
メソッドの補完が出来る。 ダックタイピングはメソッドから型を逆算するから補完が出来ない。
まぁ、やろうと思えば出来るんだろうが、型の候補が複数出てくる、
Hackもdartと同じで実際は動的型付けだが、補完がしやすいよう言語仕様的に型が書けるようになる。
Re: (スコア:1)
問題は、多くのPHPプログラマ及びプロジェクトにPHPを導入するPMがそうした利点を理解できるかどうかですかねぇ。理解できていればそもそもPHPを選択しないでしょうし。
自分の経験した範囲ですが、PHP(しか知らない)プログラマはとにかくエラーが嫌いなように思います。Internal Server Errorで何も表示されないよりも、壊れていてもいいから何か画面が出ていれば安心するというか。なので、静的型チェックを行ってエラーになるよりも、型チェックしなくてログにnoticeを山盛り出していたほうがいいという感じです。なんせ、シンボルチェックすら拒否するような文化ですから。。。
Re:静的型付けの利点 (スコア:1)
つまり、想定外のエラーが起きた時、
「ブラウザ表示がまっさらなのは安全性を考慮して
処理を中断させているからです」って言っても顧客は分かってくれないだろうから、
とにもかくにも、ある程度の見た目だけは取り繕いたいとか。
特にWebサイト系のお仕事では、そういう傾向が強いんじゃないかと邪推します。