元スレ【PHP】PHPフレームワーク総合スレ14

php覧 / PC版 /

みんなの評価 :

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

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

803 = :

みんな自分の信じた宗教にまい進すればいいんだよ

804 = :

そうそう。特に技術に面倒臭がりは、自分が知っているものを極めればいいだけ。
新しいものを触りもせずに批判している暇はない。

805 = :

>>802
海外でもyiiはそこそこじゃないかな。
はやっているとは言い難いけど注目はされてる。

優れた人の設計したFWなら後発のほうが出来がいいのは
当たり前だからね。

807 = :

むしろ無いとフレームワークなんてかったるくて使い物にならない

810 = :

>>809
悪い、書き方が悪かった。言いたかったのはDBのテーブル定義のこと。モデル定義とは別にマニュアルでcreate tableしなくちゃいけないのよ > yii

813 = :

ORMってどこまで使ってる？
複数テーブルをjoinして処理するような場合、無駄に重い(かつ設定画道そう)そうな印象なんだけど･･･

SQL書く事なんて殆ど無い感じ？

814 = :

>>813
あくまでも自分の印象だけど

複数テーブルのJOINなんてはっきり言って関心の外という印象を受ける

典型的な親子関係については、頑張って抽象化してるのが多い
それに関しては、効率を考えなければ問題なく使える

でも、RDBに特化した、JOINとかUNIONとかそういうものを取り込んでいる
ORMってのはまだ無いような気がする
理想的な「オブジェクト」モデルまでしか考慮の範囲に無いってのが、
ORMのポリシーなんだろうな

だから、Symfonyのように、いざとなったらPDO使ってデータを配列で取ってこい、
あとからオブジェクトにしてやるから・・・というアプローチはむしろ必須だと思う

816 = :

それはZendのアプローチなのかな？
主流というなら、、テーブルを抽象化するというよりはレコードを抽象化するのが主流な気がするけど
いまだActiveRecordが強力な思想って感じで

819 = :

yiiのリレーショナルアクティブレコードはどうですかね
http://www.yiiframework.com/doc/guide/1.1/ja/database.arr

820 = :

良くできてるけどルールに融通が利かないよね
シーンナンバーである程度は変えられるけど

822 = :

融通がきいてしまったらフレームワークの利点が殺がれるって考え方もできるから
そのあたりは一長一短だよなぁ

823 = :

ところでフレームワークのnamespace対応ってどう思う？
フルパスで呼び出す事が多いから、あまり利点を感じないんだが('A`；

同namespace内ならnamespaceを記述する必要が無いからコードが短くなるとは思うが、
フレームワークと同じnamespaceを使用する事はまず無いだろうし。
use構文で別名つけるにしても、別名自体が被ってしまうと厄介な事になるし。
区切り文字がバックスラッシュだから、文字列でクラス名指定する時面倒だし。

言語的に明確にスコープが区切られるのは良い事だとは思うけど、
ぶっちゃけ使いにくくない？

824 = :

どう思うって言われてもな
あるんだから、使って欲しいなってくらいか
できればお手本を見せてくれるくらいの勢いで

これで、一応フレームワークやライブラリのクラス名を気にせず
こっち側でのクラス命名ができるようになった、ってくらいの認識

ZendFrameworkの命名規則で十分だったとか言っちゃだめなんだろうな1

825 = :

極端な言い方をすれば、クラス名が名前空間の替わりだったPHPに、
今更名前空間を導入したところで、これまでの利用者の意識に大した
変革は無いだろうと

むしろ、グローバル関数万歳な書き方をしていた人らへのインパクトの
方が大きいのではないかな
現実として言語仕様的にはある意味、やっと十数年前のPerl5のpackageに
追いついただけじゃないのかと思わないでもない

もちろん、新規でPHPを始める人間にとっては全然違った意味がある
必要な変更だったとは思うけど

826 = :

>>824
>ZendFrameworkの命名規則で十分だった
ぶっちゃけそうなんだよねｗ
区切り文字が「_」から「\」に変わって、多少構文が追加が追加されたイメージしか無いんよ。

>>825
あぁ･･･その発想は無かったわ。
確かにクラスに名前空間を含める風趣の内人には革命的かもしれないね。
ふむふむ･･･

今PEARやZENDの記法も次第にnamespaceに統合されるのかなぁ･･･
バックスラッシュは微妙だなぁｗ

827 :

最初にPEARがあった。
なのに、CakePHPやSymfonyの命名規則がなんであんなに糞なのか理解不能

828 = :

言語として推奨コード規約が欲しかったよな・・・残念

831 = :

>>830
＞CakePHPやSymfonyの命名規則が糞すぎるから
＞PHPが糞言語とは思わない。糞だと思う言語を使うお前の職能は糞だと思うが。

え？どういう理解力してんだお前？
頭悪すぎる上に妄想激しすぎだろ。

833 = :

date系の新クラスとかも、何故か関数版も提供されてるしなｗ
PHP創始者が言ってたけど、言語の汚さは別に問題では無く、結果的に何が出来るかが重要らしい。

インタビューがあるから一度読んでみるといいよ。
http://gihyo.jp/news/interview/2010/rasmus

834 :

>>832
だから糞言語のスレで糞野郎のお前何してんの？

835 = 834 :

>>833
㌧

836 = :

PHPは糞まみれで前に進んでく感じがイイんじゃないか。

837 = :

お前、俺をバキュームカーとまちがえてんじゃねえのか？

838 = :

PHPはショボイけど、PHPを使わざるを得ない状況って言うのは多い。

839 = :

泥臭い言語でもいいよ、必要があれば使うだけ
でもやっぱり、namespaceのバックスラッシュは
日本語環境だとがっかりしちゃう(´･ω･`)

841 = :

銭のマークに見えるのがいけないのじゃなくて、
それはエスケープ記号だって意識が先に立つのがどうしようもなく引っかかる

842 = :

Rasmus Lerdorfが、組込み関数の引数の取り方が関数ごとにバラバラだけど別に良いじゃない？とか、
全然使わない関数が組込みに入ってるけど外そうとは思わない、みたいな事言ってるの聞いて、ああ、PHPってやっぱそういう言語なんだなって思った。

843 = :

スレタイ読もうぜ

844 = :

>>842
引数の順序がバラバラだが「目標を完遂するのに問題無い」と言っているし、
当人のインタビューｗｐ読む限り、言語自体は暗に汚いと認めてるよねｗ

まぁ、それがメリットでもありデメリットでもあるんだと思う。

いきなり型宣言必須で、全関数メソッドがCamelCaseに変わり、内部言語はutf-8に統一しました！
とか言われたら誰も移行しないだろう(もしくは完成～移行までに数年以上かかる)

そういう言語が必要ならそういう言語を使えばいい、って思想なんだろう。

846 = :

>>840
>>841

自分は正規表現書くときとか￥じゃないと書けない体になってしまったんだが。。
バックスラッシュだとパッと見/と区別しづらいし。

848 = :

円記号+なにか　でエスケープ文字って感じで目が覚えちゃってるから
たまに正しいバックスラッシュ記号をみると逆に違和感覚えちゃうｗ

849 = :

>>848
すげーわかる

850 = :

PHPも無名関数が使えるようになったり、だいぶマシになってきた。後はarray()のシンタックスシュガーだな。