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

php覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

551 = :

Rubyは引数が一つの時()を省略できるのに
PHPは省略できないんですかぁ？
ださーい

552 = :

>>551
VBなら引数がいくつでも()を省略できるぞ！
カッコイイだろ！

ただし戻り値が無い場合ね

553 = :

Rubyでもできますよーだ
VBなんて中二みたいの名前の言語使いませんよぉ
ださーい

554 = :

>>550
返ってくるデータが二次元の表だけって面倒だよね。

たとえばアドレス帳があったとして、電話番号を複数登録できるようにしたい。
まあ、普通は正規化する。んで、それを取得すると

ID, 名前, 電話番号ID, 電話番号
1, 山田, 1, 090-0000-0000
1, 山田, 2, 090-0000-0001
1, 山田, 3, 090-0000-0002
2, 佐藤, 4, 090-0001-0000
2, 佐藤, 5, 090-0001-0001
2, 佐藤, 6, 090-0001-0002

こうなる。階層的に取得できたらどんなに使いやすいか。

556 = :

できるかどうかならできた方が当然良い
関数と変数の区別をはっきりつけたいから使おうとは思わないけど

557 = :

きっちりルール決めて統一してくれたほうがいい、って意見もあると思うぜ

558 = :

その辺はコーディング規約でやるべきじゃないの？
いろんな人がいるだろうし

559 = :

>>554
PDO使えばできる

560 = :

あれは賛否両論だろ。
引数省略に付随する問題も一緒に抱えるのに
手放しで喜ぶ馬鹿は死んだほうがいい

561 = :

>>559
できねーよ

562 = :

>>561
できるーよ

563 = :

>>554
それがリレーショナルDBだから。
オブジェクトで扱いたいなら、ORMじゃなくって、OODBを使えばいいんだよ。誰も使ってないけど。
もっともその例って、単なる配列のデータ構造を表してるだけで、オブジェクトとは関係ないと思うけど。

564 = :

>>563
そりゃ、元のレスが
> 連想配列ですべて解決する。
だからだろうね。

RDBの結果なら連想配列で全て表すことができるっていうだけの書き込みに対して、
それが便利なのか？っていうつっこみなんだろうと思った。

>>554が例に挙げてる様なデータなら、多次元の配列で処理する人も多いだろうし
O/Rマッパとはまた違う次元の話の様な気もするｗ

565 = :

というか、そんな陳腐な工夫を語れるような小さくて整ったデータベースしか扱ってないんだな、おまえら。

566 = :

PHPですよ？しかも（主に配布されてる）フレームワークのスレ。

そんなに複雑でビジネスロジックとその他もろもろの制約によって
アドホックばりばりのシステムの話なんてするところじゃないじゃ無いか

567 = :

PHPでビジネスロジックや「そのたもろもろ」の制約を必要とするよーな設計するか？
そういう制約が意味あるのって、DB専門班とぎっちぎちに分業するようなケースだしなあ。
null拒否くらいならデバッグの意味はあると思うけど
PHPみたいな上層で使うモンなら正規形も凝らんでそ
制約意識するくらいなら処理ロジックや自前キャッシュ手法に凝った方が百倍マシ
PHPが生かせるケースじゃない

なんか元コメ辿ると、bindやprepare使えば十分だろ的な思惑も感じるけど

568 = :

言語で設計が決まるわけじゃない

571 = :

>>562
どうやって？サンプルコード示して。

572 = :

マニュアル読めーよ

573 = :

ま、そーやって逃げるのは分かってたからいいけど

574 = :

低脳おーつ

575 = :

お前、ほんと残念なやつだな

576 = :

しょーもない煽りあいｗｗｗ

577 = :

反応するおまえもだよｗ

578 = :

PEAR使う時ってラップしたクラス書く？
そのまま使う？

579 = :

時と場合によーる

580 = :

PDOで階層構造表現できるの？まじ？

581 = :

マジ。ただし、O/Rマッパーが必要

O/Rマッパー最高！！！

という流れですね。わかります。

583 = :

>>549
そうだね。
「ハッシュの配列では扱いにくい」と言ってるってことは、
PDOが連想配列で返すのを不便だと感じているという事だもんね。

俺は>>550と同意見だった。
オブジェクトが返ってくる事自体にまったく利点を感じないのだ。

データベースエンジンの差異を吸収するのはORMの副産物だと思うし、
それをやってくれるORMじゃないライブラリは好きなので、
やっぱり俺は世にあるORMにはあまり意義を感じていないのかも知れない。

バリエーションって何？

584 = :

>>583
そもそもオブジェクト指向に意義を感じてないんじゃない？

585 = :

オブジェクト指向で分析→設計→実装するとき、オブジェクト指向プログラミングの形とマッチしますね。
http://itpro.nikkeibp.co.jp/article/lecture/20070419/268987/

モデリングの過程がオブジェクト指向じゃないと、あまり劇的に便利という実感は湧かないかな？

586 = :

>>583
RailsのARとか使ったことあるの？

587 = :

公開されたキモゲータウンのフレームワークがPerlで作られててPHP脂肪ｗｗｗ

588 = :

むしろ歓喜しているように見える

589 = :

ひさびさに脂肪ネタ来たｗ

590 = :

CSSもDRYを求められるよな
単にデザインセンスだけでなくプログラマ的な素養が必要
お前らのデザイナはDRYでびゅーちふるなCSSを書けるの？
それともお前らが手直しするの？

591 = :

なんでそれをこのスレで聞くん？

592 = :

>>590
因みに俺のところでは手直しも指導も回答も全部俺がやっている。
つうか、エディタを使う作業は、たいがい俺に回ってくる。
一度も書いたことがないASをいきなり書けたら天才呼ばわりされた。
ほとんど使わないエクセルでマクロをいきなり書いたときもそうだった。
冗談じゃない、感心するなら金くれと言いたい。
うぇぶでざいなー（笑）の100倍は貰って当然だろ、本気で。

593 = :

DBの結果セットをそのままクラスにするなんてJava屋の発想だな。もしくはアカデミックな人の発想だ。実戦的じゃない。
ウェブアプリって、一覧画面なら連想配列の配列、詳細画面なら連想配列でDBから情報を取得して、HTMLという静的な状態に移す、ほとんどはそれで済む話。
複雑なロジックを伴うクラスが必要な場合だけクラスにすればいい。そういうクラスはDBからだけで構成されるわけじゃない。ORMからさらにDAOと2重にラップする必要はない。

594 = :

まあぶっちゃけJavaには連想配列はないから、どうやったってオブジェクトにはなるんだけどな
それをモデルとして便利にする方向はある意味自然か

595 = :

Zendが身売り準備開始してPHPリアルに脂肪ｗ

598 = :

もしPHPが有料の製品になったらどうする？
俺は捨てるｗｗｗ

599 = :

なるわけねえだろ。さすがに。

600 = :

Microsoftが買収したら、なにやらワケが判らぬフレームワークが前提になって、
そのフレームワークの機能はIISでしか動かないみたいなのはあるかもよ。

あぁ、想像しただけで嫌だ。