元スレ【PHP】フレームワークについて語るスレ13【総合】

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

351 = :

>>349
論点ずれすぎ。
クラスタイプヒンティング自体が実装されている以上、意味が無いという事は無い。

あと例えが頭悪すぎかつ意味不明。
そんな用途しか思いつかない君には意味が無いのかもしれないな･･･

352 = :

>>351
こんな所で他人に「頭悪い」とか言ってる暇があったら
頭良いお前が気に入るようにPHPの言語仕様に実装しちゃえば
いいと思うけど～

353 = :

すごい言い様だな

354 = :

>>349
え？ＰＯＳＴから数値を受け取りたい場合、普通は型チェックしてｉｎｔに変換するよね？

355 = :

HTTPは数値も全て文字列で渡されるからなぁ。

これがC言語であっても、結局は文字列から数値に変換する必要があるわけだ。
手間は何も変わらない。

356 = :

>>349
それ違う話。難しい話してごめんな。

>>352
オマエモナー

357 = :

あーだこーだ言う前にここ二ヶ月くらいのinternal読んどけ。

358 = :

型指定否定派はプログラマとしての能力(デバッグ力)が低そうなイメージだな･･･

・privateとかいらないよね！
・interfaceとか何につかうの？ｗ
・abstract？面倒なだけじゃんｗ
・そもそもclass化すると速度遅くなるし！
・テンプレートエンジン？いらねｗ　PHP自体がテンプレートエンジンだからｗ

359 = :

残念だがそれらは型指定とは関係ない

360 = :

あくまでイメージだよ･･･使いこなせないから不要って人がPHP使いには多い気がする
で、他の言語もかじってる人がツッコミを入れると袋だたきにされる･･･と。

361 = :

最初に触った言語がPHPの人ってかわいそうだよね。
その後もプログラマーとして成長できなさそう。

362 = :

自分がついていけないから、言語の進化を否定している感じだよね
無名関数とかネームスペースとか、浸透しなさそうだなぁ

363 :

むしろ型指定にうるさいだけの奴の方が初心者くせー
分かりきってること言ってるだけだし
代替案示されてもふてくされる
ただの馬鹿ですね分かります

364 = :

コード内で型チェックして例外投げるのが面倒だから、
組み込み型もタイプヒンティングしたいって話じゃないの？

代替え案なんてあったっけ･･･？

365 = :

// 型指定あり
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();
}

366 = :

オプションとしてあっても誰も困らないんだから
あった方がいいのは疑問の余地がねーんだよ
ただ文句言ってるだけなのが頭悪い

368 = :

型指定ﾏﾝｾｰ派は、コーディングのときなんかに、決められた型しか渡せないのがわかるから、
バグを作りこむ可能性が少ない、とか、自分が書くメソッドでチェックしなくてすむから便利つってて、
チェック処理でいいだろ派は、渡される値の型がわからないものを処理する場合
メソッド内でチェックするか外でチェックするかの違いしかないから、
結局チェックかませりゃいいだけじゃん
つってる
そこらへんをお互いが理解してないのか知らんけど、話かみ合ってねーだろｗ

つか、指定できれば便利、ってのはみんなわかってるだろう
でもぐだぐだ不満垂れようが、結局いまのPHPじゃできないんだから
ここで愚痴るのも馬鹿な話というかお門違い。フレームワークにも関係ねーし

だいたいそういうのはPHPを使うと決めた時点で割り切るべき機能だと思うけどな
型指定できない仕様が向いてないもの作るなら、まずPHPを選択肢から除外するべきじゃ

369 = :

>>368
最後の2行が余計だな。
スレ違かもしれんが、PHP5以降に対する要望としてはお門違いでも無いし、
嫌なら他の言語使えってのは極論過ぎる。

370 = :

お門違いだよ

371 = :

お門違いじゃないよ

372 = :

理由を言えよ、たこ助野郎

373 = :

みんなで芋堀りすればいいんじゃね？

374 = :

タイプヒンティング
http://php.benscom.com/manual/ja/language.oop5.typehinting.php

375 = :

落ちて久しいPHP総合スレたててそっちでやれｗ

376 = :

>>369
お前がいやだと思ってることはもう十二分にわかったから、日記帳にでも書いてろｗ

377 = :

ちょっと質問なのだけど、
2～3枚の軽いけど、DBを一応使う。みたいな要件の時FW使うまでもないかなと考えてるのですが、
そういう時皆はどうやって作ってますか？
規模に関係なくFW使ってる？
それとも、pdoとか使ってべた書き？

378 = :

>>377
俺個人でやるならベタで書くな。その方が軽いし管理も楽だ。
仕事でやるなら周りのシステムに合わせておく。

379 = :

>>355
ああ、それは大きいな。しょせんHTTP（というかHTML）には限界がある。
try {
int $num = $_REQUEST['age'];
} catch (Exception $e) {
die("age is not number");
}
こういうのがベスト。連想配列とかオブジェクトを直接REQUEST出来たり名。

380 = :

>>379
なにそのコードこわい。

HTTPの限界？そもそも型を保証するようなプロトコルじゃないだろう。

381 = :

phpとかhttpとか限界じゃなくて仕様と割り切るのが精神衛生上いいし、そういうもんじゃないのか

382 = :

>>378
レスどうもありがとうございます。

コピーしてちょっと設置とか取り回しが面倒だし、
propelだけ入れるってのも手間かけるメリット薄いので、躊躇してました。

383 = :

コツコツと自前の関数郡作ってる
そして会社には絶対に持っていかない

384 = :

>>379
小さいプロジェクトはいいな。

385 = :

>>379 のコードが理解出来ないのは俺だけか

386 = :

Integer型の $num に Integer 以外の型で値が渡ってきたら
おかしいことなので例外が発生。
そのとき「値がおかしいぜ！」ってダイイングメッセージ残して
phpが死ぬって意味だろ。

しかしせめて
int $num = Integer.parseInt($_REQUEST['age']);
とかだろ。

387 = :

例外の使い方が不適切なような・・

388 = :

想定外の値が来たからキャストエラーだろ？
何か問題でも？

389 = :

PHPの無茶キャストっぷりを考えたら意図した通りに動くとは思えないがｗ


そもそも、それはPHPのコードなのか？

390 = :

論争

静的および強い型付けの支持者と動的および自由な型付けの支持者の間では衝突が度々おきる。
前者のグループは厳密な型付けの使用によって、処理系がより多くのエラーを
問題が大きくなる前に発見できるようになると主張している。
後者のグループはより気軽な型付けによってコードはよりシンプルなものになり、
そのようなコードは解析しやすいとされるので、エラーは減少すると主張している。
型推論がある言語では型を手で宣言する必要はほとんどないので、強い型付けに伴う開発のオーバーヘッドは低減される。

個人がどのグループに分かれるかは、開発しているソフトウェアの種類やチームのメンバーの能力、
他のシステムとの対話性の度合い、開発チームの規模などに依ることが多い。
少人数で小回りのきくプロジェクトには気軽な型付けがより合い、フォーマルで大人数で仕事が分断されている
（プログラマ、アナリスト、テスト部隊、など）プロジェクトは厳密な型付けのほうがうまくいくことが多い、と結論づける者もいる。

391 = :

一般に動的な型付けを持つ言語では型の特性に合わせた最適化(例えば常に浮動小数点レジスタを用いるなど)ができないので、
実行速度という面では静的型に劣ると考えられている。反面多態性や記述の容易さで動的型は融通が利き、
Smalltalkなどのオブジェクト指向言語、スクリプト言語は動的型を採用するケースが多い。

動的型と静的型のどちらが安全なプログラムを記述できるのかは長年論争の的であるが、
双方とも適した問題領域、適した開発スタイルが存在し、異なった安全観念を持つ点を理解しなければならない

通常、静的型付けはオペレーティングシステムやシステムプログラムのような大規模で厳密性が要求される領域に適合するといわれている。
反面最初の型定義を誤ると一部分の影響が全体に波及すること、また柔軟性に乏しくわずかな変換に手間のかかる経路を用意したり
同じような機能を型別に実装しなければならないことなど、いわばお役所仕事的な煩雑さを伴うという弱点を持つ。
（なお近年の研究により静的型付けの言語も文脈から型を推論する型推論能力を持つなど簡略化の方向へ向かってはいる）

一方動的型付けの言語ではそもそも対象に特定の構造を期待しないため変更への対応は柔軟である。
特に配列、辞書、集合といったコレクションの利便性が顕著で、そのため近年いわゆるスクリプト言語は多くが動的型付けを採用している。
動的型付けの難点である最適化の弱さは、コンピューターの能力が増すことで相対的に小さな問題になっており、
スクリプト言語を中心に今後も動的型付けは発展するものと思われる。

392 = :

実行パフォーマンスには期待していない。
部分的に強い型付けが出来る程度がPHPの理想系な気がする。

394 = :

どんなに言語が簡単で優れていても、
ライブラリが揃ってない時点でPHPerは移行しないだろ。

なぜなら自前で実装する知識が無いから。
フォームデータのパースすら出来ない人がほとんどなんじゃない？

395 = :

つーまーりー？

396 = :

仕事で使う言語を自由に選べたらこんなスレにいねーよ

397 = :

まったくだな

398 = :

だーけーどー？

399 = :

>>377
俺は自作のフレームワークもどきを使っているよ。
最小でPHPファイル1つで完結する。
フレームワークというより、ファイルの置き方を決めた程度だけどな。

PHPを使わないでベタで書いたものから
簡単に移行できる設計になっているから、
ベタでかいていたけど、PHPファイルが数枚になって
ディレクトリ構造とか考え出したときに、すぐに変更できる。

400 = :

それを今すぐ公開しろ。今すぐだ

前へ 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 ○