>>800
独自かどうかは関係無く、
Zend/Symphony/cake/CI/Ethna･･･ どれも日本のコミュニティがあり、ある程度盛り上がっている。

で、海外ではyii流行ってるの？ｗ

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

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

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

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

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

yiiはscaffoldの生成のツールとかwidgetの仕組みとかかなり良くできていると思うんだけどさ、モデルを
FW内で定義したらそのモデルを実現するためのSQLをいちいち手で書かないといけないんだ。これが面倒。
fixtureの記述だって全部手作業。symfony/Doctrine はこれらを自動でやってくれくれるから楽。yamlに
モデル定義を書けばSQLは自動生成だし、DBからリバースしてfixtureを作ってくれる。cakeやCIは
俺ほとんど知らないんだけどその辺どうなってんの？

scaffoldingは基本的に今時のframeworkなら実装されてる。

SQLを手で書く必要があるの意味は解らない。やり方間違ってない？

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

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

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

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

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

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

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

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

>>814
なるほど、One Object = One Table という実装や使い方が主流って感じですかね。
自分の場合は、以下のように
・1テーブルの1行をCRUD
・1テーブルの複数行をSELECT
程度にしか使っていなかったので、皆さんの意見を聞きたいです。

$table = new HogeTable();
$rowList = $table->fetch()
$row = $rowList->fetch();
$row = $table->createRow();

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

>>816
うん。Zendメインに使ってるんだ。
未だにデザインパターンが良くわかってないんだけど、
ゲートウェイパターンとActiveRecordってPHPコードにするとどんな感じになるんだろ

ActiveRecordってのは曲者といえば曲者なのかも
レコードの抽象化(save()メソッドなど)かと思えば、同じオブジェクトが
find_by() みたいなデータ集合（テーブル？）の抽象化みたいな機能も持ってるし

ぶっちゃけ、便利なのは認めるが、意味はよくわからん
俺だけかな

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

PHP自体、やっと後付けで最近汚いネームスペースがついたばかりの糞言語なのに、
なんでいまさら命名規則に文句を言うのか理解不能

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

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

標準関数の命名規則がアレなのに糞言語だとは思わないんだな。
不思議。

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

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

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

>>833
㌧

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

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

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

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

変な文字セット使ってるから

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

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

スレタイ読もうぜ

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

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

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

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

>>840
>>841

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

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

>>848
すげーわかる

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