私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】フレームワークについて語るスレ13【総合】
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
>>349
論点ずれすぎ。
クラスタイプヒンティング自体が実装されている以上、意味が無いという事は無い。
あと例えが頭悪すぎかつ意味不明。
そんな用途しか思いつかない君には意味が無いのかもしれないな・・・
論点ずれすぎ。
クラスタイプヒンティング自体が実装されている以上、意味が無いという事は無い。
あと例えが頭悪すぎかつ意味不明。
そんな用途しか思いつかない君には意味が無いのかもしれないな・・・
>>349
え?POSTから数値を受け取りたい場合、普通は型チェックしてintに変換するよね?
え?POSTから数値を受け取りたい場合、普通は型チェックしてintに変換するよね?
HTTPは数値も全て文字列で渡されるからなぁ。
これがC言語であっても、結局は文字列から数値に変換する必要があるわけだ。
手間は何も変わらない。
これがC言語であっても、結局は文字列から数値に変換する必要があるわけだ。
手間は何も変わらない。
型指定否定派はプログラマとしての能力(デバッグ力)が低そうなイメージだな・・・
・privateとかいらないよね!
・interfaceとか何につかうの?w
・abstract?面倒なだけじゃんw
・そもそもclass化すると速度遅くなるし!
・テンプレートエンジン?いらねw PHP自体がテンプレートエンジンだからw
・privateとかいらないよね!
・interfaceとか何につかうの?w
・abstract?面倒なだけじゃんw
・そもそもclass化すると速度遅くなるし!
・テンプレートエンジン?いらねw PHP自体がテンプレートエンジンだからw
あくまでイメージだよ・・・使いこなせないから不要って人がPHP使いには多い気がする
で、他の言語もかじってる人がツッコミを入れると袋だたきにされる・・・と。
で、他の言語もかじってる人がツッコミを入れると袋だたきにされる・・・と。
最初に触った言語がPHPの人ってかわいそうだよね。
その後もプログラマーとして成長できなさそう。
その後もプログラマーとして成長できなさそう。
自分がついていけないから、言語の進化を否定している感じだよね
無名関数とかネームスペースとか、浸透しなさそうだなぁ
無名関数とかネームスペースとか、浸透しなさそうだなぁ
むしろ型指定にうるさいだけの奴の方が初心者くせー
分かりきってること言ってるだけだし
代替案示されてもふてくされる
ただの馬鹿ですね分かります
分かりきってること言ってるだけだし
代替案示されてもふてくされる
ただの馬鹿ですね分かります
コード内で型チェックして例外投げるのが面倒だから、
組み込み型もタイプヒンティングしたいって話じゃないの?
代替え案なんてあったっけ・・・?
組み込み型もタイプヒンティングしたいって話じゃないの?
代替え案なんてあったっけ・・・?
// 型指定あり
function hoge(string $str, int $int, boolean $bool)
{
}
// 型指定無し
function hoge($str, $int, $bool)
{
if (!is_string($str)) new throw InvalidArgumentException();
if (!is_int($int)) new throw InvalidArgumentException();
if (!is_bool($bool)) new throw InvalidArgumentException();
}
function hoge(string $str, int $int, boolean $bool)
{
}
// 型指定無し
function hoge($str, $int, $bool)
{
if (!is_string($str)) new throw InvalidArgumentException();
if (!is_int($int)) new throw InvalidArgumentException();
if (!is_bool($bool)) new throw InvalidArgumentException();
}
オプションとしてあっても誰も困らないんだから
あった方がいいのは疑問の余地がねーんだよ
ただ文句言ってるだけなのが頭悪い
あった方がいいのは疑問の余地がねーんだよ
ただ文句言ってるだけなのが頭悪い
PHPのマニュアルでは、型指定も戻り値指定もあるんだよねぇ・・・
PHPDocで同様のマニュアルを出力したいんだけど、
現状では@paramに型までキッチリ書かないといけないから面倒すぎる。
PHPDocで同様のマニュアルを出力したいんだけど、
現状では@paramに型までキッチリ書かないといけないから面倒すぎる。
型指定マンセー派は、コーディングのときなんかに、決められた型しか渡せないのがわかるから、
バグを作りこむ可能性が少ない、とか、自分が書くメソッドでチェックしなくてすむから便利つってて、
チェック処理でいいだろ派は、渡される値の型がわからないものを処理する場合
メソッド内でチェックするか外でチェックするかの違いしかないから、
結局チェックかませりゃいいだけじゃん
つってる
そこらへんをお互いが理解してないのか知らんけど、話かみ合ってねーだろw
つか、指定できれば便利、ってのはみんなわかってるだろう
でもぐだぐだ不満垂れようが、結局いまのPHPじゃできないんだから
ここで愚痴るのも馬鹿な話というかお門違い。フレームワークにも関係ねーし
だいたいそういうのはPHPを使うと決めた時点で割り切るべき機能だと思うけどな
型指定できない仕様が向いてないもの作るなら、まずPHPを選択肢から除外するべきじゃ
バグを作りこむ可能性が少ない、とか、自分が書くメソッドでチェックしなくてすむから便利つってて、
チェック処理でいいだろ派は、渡される値の型がわからないものを処理する場合
メソッド内でチェックするか外でチェックするかの違いしかないから、
結局チェックかませりゃいいだけじゃん
つってる
そこらへんをお互いが理解してないのか知らんけど、話かみ合ってねーだろw
つか、指定できれば便利、ってのはみんなわかってるだろう
でもぐだぐだ不満垂れようが、結局いまのPHPじゃできないんだから
ここで愚痴るのも馬鹿な話というかお門違い。フレームワークにも関係ねーし
だいたいそういうのはPHPを使うと決めた時点で割り切るべき機能だと思うけどな
型指定できない仕様が向いてないもの作るなら、まずPHPを選択肢から除外するべきじゃ
>>369
お前がいやだと思ってることはもう十二分にわかったから、日記帳にでも書いてろw
お前がいやだと思ってることはもう十二分にわかったから、日記帳にでも書いてろw
ちょっと質問なのだけど、
2~3枚の軽いけど、DBを一応使う。みたいな要件の時FW使うまでもないかなと考えてるのですが、
そういう時皆はどうやって作ってますか?
規模に関係なくFW使ってる?
それとも、pdoとか使ってべた書き?
2~3枚の軽いけど、DBを一応使う。みたいな要件の時FW使うまでもないかなと考えてるのですが、
そういう時皆はどうやって作ってますか?
規模に関係なくFW使ってる?
それとも、pdoとか使ってべた書き?
>>355
ああ、それは大きいな。しょせんHTTP(というかHTML)には限界がある。
try {
int $num = $_REQUEST['age'];
} catch (Exception $e) {
die("age is not number");
}
こういうのがベスト。連想配列とかオブジェクトを直接REQUEST出来たり名。
ああ、それは大きいな。しょせんHTTP(というかHTML)には限界がある。
try {
int $num = $_REQUEST['age'];
} catch (Exception $e) {
die("age is not number");
}
こういうのがベスト。連想配列とかオブジェクトを直接REQUEST出来たり名。
phpとかhttpとか限界じゃなくて仕様と割り切るのが精神衛生上いいし、そういうもんじゃないのか
>>379
小さいプロジェクトはいいな。
小さいプロジェクトはいいな。
>>379 のコードが理解出来ないのは俺だけか
Integer型の $num に Integer 以外の型で値が渡ってきたら
おかしいことなので例外が発生。
そのとき「値がおかしいぜ!」ってダイイングメッセージ残して
phpが死ぬって意味だろ。
しかしせめて
int $num = Integer.parseInt($_REQUEST['age']);
とかだろ。
おかしいことなので例外が発生。
そのとき「値がおかしいぜ!」ってダイイングメッセージ残して
phpが死ぬって意味だろ。
しかしせめて
int $num = Integer.parseInt($_REQUEST['age']);
とかだろ。
PHPの無茶キャストっぷりを考えたら意図した通りに動くとは思えないがw
そもそも、それはPHPのコードなのか?
そもそも、それはPHPのコードなのか?
論争
静的および強い型付けの支持者と動的および自由な型付けの支持者の間では衝突が度々おきる。
前者のグループは厳密な型付けの使用によって、処理系がより多くのエラーを
問題が大きくなる前に発見できるようになると主張している。
後者のグループはより気軽な型付けによってコードはよりシンプルなものになり、
そのようなコードは解析しやすいとされるので、エラーは減少すると主張している。
型推論がある言語では型を手で宣言する必要はほとんどないので、強い型付けに伴う開発のオーバーヘッドは低減される。
個人がどのグループに分かれるかは、開発しているソフトウェアの種類やチームのメンバーの能力、
他のシステムとの対話性の度合い、開発チームの規模などに依ることが多い。
少人数で小回りのきくプロジェクトには気軽な型付けがより合い、フォーマルで大人数で仕事が分断されている
(プログラマ、アナリスト、テスト部隊、など)プロジェクトは厳密な型付けのほうがうまくいくことが多い、と結論づける者もいる。
静的および強い型付けの支持者と動的および自由な型付けの支持者の間では衝突が度々おきる。
前者のグループは厳密な型付けの使用によって、処理系がより多くのエラーを
問題が大きくなる前に発見できるようになると主張している。
後者のグループはより気軽な型付けによってコードはよりシンプルなものになり、
そのようなコードは解析しやすいとされるので、エラーは減少すると主張している。
型推論がある言語では型を手で宣言する必要はほとんどないので、強い型付けに伴う開発のオーバーヘッドは低減される。
個人がどのグループに分かれるかは、開発しているソフトウェアの種類やチームのメンバーの能力、
他のシステムとの対話性の度合い、開発チームの規模などに依ることが多い。
少人数で小回りのきくプロジェクトには気軽な型付けがより合い、フォーマルで大人数で仕事が分断されている
(プログラマ、アナリスト、テスト部隊、など)プロジェクトは厳密な型付けのほうがうまくいくことが多い、と結論づける者もいる。
一般に動的な型付けを持つ言語では型の特性に合わせた最適化(例えば常に浮動小数点レジスタを用いるなど)ができないので、
実行速度という面では静的型に劣ると考えられている。反面多態性や記述の容易さで動的型は融通が利き、
Smalltalkなどのオブジェクト指向言語、スクリプト言語は動的型を採用するケースが多い。
動的型と静的型のどちらが安全なプログラムを記述できるのかは長年論争の的であるが、
双方とも適した問題領域、適した開発スタイルが存在し、異なった安全観念を持つ点を理解しなければならない
通常、静的型付けはオペレーティングシステムやシステムプログラムのような大規模で厳密性が要求される領域に適合するといわれている。
反面最初の型定義を誤ると一部分の影響が全体に波及すること、また柔軟性に乏しくわずかな変換に手間のかかる経路を用意したり
同じような機能を型別に実装しなければならないことなど、いわばお役所仕事的な煩雑さを伴うという弱点を持つ。
(なお近年の研究により静的型付けの言語も文脈から型を推論する型推論能力を持つなど簡略化の方向へ向かってはいる)
一方動的型付けの言語ではそもそも対象に特定の構造を期待しないため変更への対応は柔軟である。
特に配列、辞書、集合といったコレクションの利便性が顕著で、そのため近年いわゆるスクリプト言語は多くが動的型付けを採用している。
動的型付けの難点である最適化の弱さは、コンピューターの能力が増すことで相対的に小さな問題になっており、
スクリプト言語を中心に今後も動的型付けは発展するものと思われる。
実行速度という面では静的型に劣ると考えられている。反面多態性や記述の容易さで動的型は融通が利き、
Smalltalkなどのオブジェクト指向言語、スクリプト言語は動的型を採用するケースが多い。
動的型と静的型のどちらが安全なプログラムを記述できるのかは長年論争の的であるが、
双方とも適した問題領域、適した開発スタイルが存在し、異なった安全観念を持つ点を理解しなければならない
通常、静的型付けはオペレーティングシステムやシステムプログラムのような大規模で厳密性が要求される領域に適合するといわれている。
反面最初の型定義を誤ると一部分の影響が全体に波及すること、また柔軟性に乏しくわずかな変換に手間のかかる経路を用意したり
同じような機能を型別に実装しなければならないことなど、いわばお役所仕事的な煩雑さを伴うという弱点を持つ。
(なお近年の研究により静的型付けの言語も文脈から型を推論する型推論能力を持つなど簡略化の方向へ向かってはいる)
一方動的型付けの言語ではそもそも対象に特定の構造を期待しないため変更への対応は柔軟である。
特に配列、辞書、集合といったコレクションの利便性が顕著で、そのため近年いわゆるスクリプト言語は多くが動的型付けを採用している。
動的型付けの難点である最適化の弱さは、コンピューターの能力が増すことで相対的に小さな問題になっており、
スクリプト言語を中心に今後も動的型付けは発展するものと思われる。
実行パフォーマンスには期待していない。
部分的に強い型付けが出来る程度がPHPの理想系な気がする。
部分的に強い型付けが出来る程度がPHPの理想系な気がする。
どんなに言語が簡単で優れていても、
ライブラリが揃ってない時点でPHPerは移行しないだろ。
なぜなら自前で実装する知識が無いから。
フォームデータのパースすら出来ない人がほとんどなんじゃない?
ライブラリが揃ってない時点でPHPerは移行しないだろ。
なぜなら自前で実装する知識が無いから。
フォームデータのパースすら出来ない人がほとんどなんじゃない?
>>377
俺は自作のフレームワークもどきを使っているよ。
最小でPHPファイル1つで完結する。
フレームワークというより、ファイルの置き方を決めた程度だけどな。
PHPを使わないでベタで書いたものから
簡単に移行できる設計になっているから、
ベタでかいていたけど、PHPファイルが数枚になって
ディレクトリ構造とか考え出したときに、すぐに変更できる。
俺は自作のフレームワークもどきを使っているよ。
最小でPHPファイル1つで完結する。
フレームワークというより、ファイルの置き方を決めた程度だけどな。
PHPを使わないでベタで書いたものから
簡単に移行できる設計になっているから、
ベタでかいていたけど、PHPファイルが数枚になって
ディレクトリ構造とか考え出したときに、すぐに変更できる。
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php スレッド一覧へ
みんなの評価 : ○類似してるかもしれないスレッド
- 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/8/24 19:04 ○
- 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/12/23 16:48 ○
- 【PHP】フレームワークについて語るスレ12【総合】 (994) - [98%] - 2009/3/19 13:46 ○
- 【PHP】フレームワーク CakePHP 3ホール目【本命】 (1001) - [59%] - 2008/6/19 7:19 ○
- 【PHP】セッションについて語ろう!【PHP】 (829) - [58%] - 2018/6/27 23:16 ○
- 【PHP】フレームワーク CakePHP 4ホール目【v1.2】 (1001) - [57%] - 2008/12/19 21:06 ○
- 【PHP】フレームワーク CakePHP 6ホール目【v1.2】 (933) - [57%] - 2009/8/19 2:06 ○
- 【PHP】フレームワーク CakePHP 5ホール目【v1.2】 (985) - [57%] - 2009/3/7 4:53 ☆
- 【PHP】フレームワーク CakePHP 7ホール目【v1.2】 (1001) - [57%] - 2010/3/18 1:18 ○
トップメニューへ / →のくす牧場書庫について