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

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

[前50を表示]
300:nobodyさん
05/10/01 21:21:42
>>299
なんでいきなりアセンブラが出てくるんだ？
比喩にしてもおかしいし？？？

301:nobodyさん
05/10/01 21:32:08
小さなプログラムを個人で書きなぐってるって人なんじゃないの？

仕事で似たような案件を多くあつかっていると、大枠で共通することが
多いことに気づいてくる。それをくくりだして同じ事を何度もしなくても
いいようにしようと思うわけだ。
言語レベルではライブラリとして共有できるようになってる。
さらに扱う対象によっては毎回似たようなプログラムの流れになることがある。
その似たような部分の構成を使いまわしできるようにしておくと、効率があがる。

299さんの言っていることも極端ではあるけど考え方としては同じこと。
アセンブラがあれば何でも記述できるけど、WEBアプリなんか書く時にはPHPが
適しているのでPHPで書く。毎回アセンブラからまずPHP（あるいは俺言語）を作って
仕事に取り組むってのは能率悪そうでしょ？

ただフレームワークを必要としない人や場合もあるのだから 290さんの言うように
必要としていない状況なのかもしれない。

302:nobodyさん
05/10/01 21:38:29
ちょっと流れ無視なのかもしれませんが、
クラス・ライブラリとフレームワークの違いって何ですか？

ライブラリ群＝フレームワーク？と思っているんですが。

303:nobodyさん
05/10/01 21:56:33
・画面遷移の仕組み
・入力データのヴァリデーション
・HTML表示のためのテンプレートエンジン
・セッション管理
・アクセス制御
あたりの機能を体系的にまとめたものが、いわゆるフレームワークと言っていいと思う。
特に上3つはフレームワークと呼ばれるものには必ず存在するかな。
ただ、それぞれの機能単独のライブラリもあるから、そういうライブラリを自分で組み合わせても構わないし、
そっちの方がいい場合もあるだろう。

304:nobodyさん
05/10/01 22:48:16
保守性のメリットもあるお

305:nobodyさん
05/10/01 22:55:55
フレームワークの意味や利点が理解できない漏れは、
当然クラスの良さも分からないし使ったこともない。
「良さが分からない」というか、「使用法を習得するほうがめんどい」。

だからPEARも一度も使ったことなく（ちょっと調べて断念）、
よく使う機能については「俺ライブラリ」（せいぜい自作関数）的なものを作って
ファイルにまとめて、それをincludeしたり部分的にコピペして貼ったりして再利用してる。
それで十分便利だし苦にも思わない。

306:nobodyさん
05/10/01 23:10:17
>>305
苦にも思わないならそれでいいんじゃないかな？
上で大規模小規模って話が出てきてるけど
大規模→大人数となってくるとそれを苦に思う人も出てくるだろう
その時になったらまた考えればいいと思う

繰り返しになるけど，最初の学習曲線をよじ登る手間が，
初めから登らなかった場合の手間の総量を上回らないなら，登らない方がトータルで良いしね

ただ経験から言わせてもらうと，
仕事でPHPをやってる限り，結果的にはたぶん総量を上回ることになると思う……

307:nobodyさん
05/10/02 00:39:45
まあ、PHPは標準関数の機能が多いから、PEAR使わなくても構わない場合は多いけどな。
Perlの場合、CGI、DBI、HTML::Template、CGI::Sessionあたりを使わざるを得ないけど。
ただし、PHPは名前空間が区切れないから、クラスを使わないとグローバル変数名の衝突をさけられない。
なんで、処理がある程度複雑になってきたら、クラスを使うしかなくなる。

308:nobodyさん
05/10/02 01:42:18
自分1人で開発してるうちは
フレームワークの恩恵はそれほどないかもしれない
小規模のものを作るのには必要ない
単純なメールフォーム作るのにフレームワークなんていらない

複数人でそれなりに規模のあるものの
開発をしようとするとそれぞれのスキルと作り方で
同じ処理の流れのものを作っていても
コードや構成はばらついていく

だから遷移方法や処理のプロセスはこういうやり方で
ここにそのコードを置いてくださいという
取り決めがフレームワークで
チーム全員がその取り決めにならって開発していく事で
誰が書いても全体の構成がある程度統一されていく部分が
フレームワークを使う事の一番のメリットなんじゃないのかな

309:nobodyさん
05/10/02 02:06:00
PHPには、PerlのCGI::ApplicationやJavaのStrutsほどメジャーなものはないし、開発者全員がそのフレームワーク自体を覚えないといけないってコストがかかる。
他にもデメリットとして、smartyのようなテンプレートエンジンを使うと実行速度がぐっと下がるし、
標準であるべきDBクラスのPEAR_DBは、標準関数と比べて圧倒的に速度が遅い。代替のDBクラスもあるけど、これも乱立していて学習コストがかかる。
さらに言うと、PHP開発者のスキルは概して低い。
PHP開発者の確保は、Perl開発者、Java開発者の確保よ低コストだけど、PHPでOOPやフレームワークを扱える開発者をそろえるのは難しい。
こういったデメリットを乗り越えて、なおフレームワークにメリットがあるかどうかを考えないといけない。

310:nobodyさん
05/10/02 02:36:39
PHPのスレで言うのもアレなんだがRubyのRails試してみるといい。
あとAppleのWebObjectsとか。Gauche(Scheme)なKahuaも
ええよ。

311:nobodyさん
05/10/02 09:25:07
ライブラリは自分の書いたコードがライブラリのコードを呼び出す
フレームワークは自分の書いたコードがフレームワークのコードから呼ばれる

基礎の基礎。

312:302
05/10/02 09:44:41
>>303
分かりやすい説明ありがとうございます。
Webアプリ用のフレームワークについてはなんとなく分かったような気がします。
でも「Mac OS XのCocoaフレームワーク」なんていうのを
聞いたことありますが、あれはHTMLとは関係ないですよね。
そういう場合はどう考えればいいのか。

>>311
呼び出す方向による分類は新鮮です。いや、これに関しては無知でした。
デスクトップ・アプリで言うところのイベント駆動型かどうかという分類でしょうか。
ありがとうございます。

313:nobodyさん
05/10/02 10:35:14
チーム開発のメリットだとしても、それフレームワーク使うより、
PECLで独自の拡張関数を増やすほうがよろしいんじゃないでしょうかね

314:nobodyさん
05/10/02 13:12:15
扱っている案件において検討した結果
そういう結論に至ったのならそういうケースもある。

当然フレームワークを利用する方が良いケースもあるでしょう。

315:nobodyさん
05/10/02 13:18:58
PECLで独自関数っていうとCで拡張モジュールを書くということ?
それがチーム開発においてプラスになるのはかなり特殊なケースに思えるけど。

ていうかそんなの実際にあるんかいな。

316:nobodyさん
05/10/02 16:48:05
あなたまかせの特定のフレームワークを使い倒すよりは、
独自拡張をあわせたほうがいい気はするけどな

317:nobodyさん
05/10/02 16:59:18
>>311
シンプルだけど本質的な定義だな。

318:nobodyさん
05/10/02 19:28:25
$context =& $this->getContext();
$controller =& $context->getController();
$request =& $context->getRequest();
------------
$controller =& $this->getContext()->getController();
$request =& $this->getContext()->getRequest();

あなたはDOTCH派？

319:nobodyさん
05/10/02 19:39:32
そもそも PHP4 じゃ前者でしか書けない罠

320:nobodyさん
05/10/02 22:32:53
どっちも意味不明派。

321:nobodyさん
05/10/02 22:42:00
後者は&いらないんじゃないか？

そんな自分は「= &$foo」派

322:nobodyさん
05/10/03 04:04:57
>>318
PHP5では&はいらないわけだが。
むしろそのへんのことも含めMojavi系は面倒くさいので、そっとごみ箱にいれた派。

323:nobodyさん
05/10/03 09:12:25
>>322
めんどくさいかなぁ？？
フレームワーク使わずにどうWebアプリ構築してるのか知りたい。
べた書き？後から見辛くない？

324:nobodyさん
05/10/03 09:14:42
別にPHP4だから、かならず参照渡ししないといけないわけじゃない。
対象のオブジェクトや配列の複雑さの程度だとか、後から値を変えたいかとかによる。

325:nobodyさん
05/10/03 10:55:25
>>324
まあ確かにそうだけどさ、プロパティを変えないつもりでオブジェクト値渡ししといたら、後々になってからやっぱりプロパティを変える操作をした場合に辻褄あわなくなるじゃん。
PHP4だったら常に参照渡しにしたほうが楽な希ガス。

326:nobodyさん
05/10/03 12:48:32
配列はよりけりだけど
オブジェクトは一律参照渡しでほとんど問題なくない？

327:nobodyさん
05/10/03 14:42:31
問題ないというか、PHP5や他の言語を考えると
必要な場面でのみ値渡しにしたほうがいいと思う

328:nobodyさん
05/10/03 15:56:03
要はオブジェクトは特に理由がないなら参照渡しにしとけって話でFA。

329:nobodyさん
05/10/03 16:02:55
ふりーえーじぇんと宣言？

330:nobodyさん
05/10/03 19:53:20
っていうか参照渡しとか値渡しとか意味わからん漏れはダメ人間。

331:nobodyさん
05/10/04 03:25:49
どうしてわかってくれないのっ！

332:nobodyさん
05/10/04 16:01:01
ティン！

333:nobodyさん
05/10/04 18:09:25
フレームワークとふかわがものすごいﾐｽﾏｯﾁだな

334:nobodyさん
05/10/04 20:38:36
　　　 _____
　　 /二二ヽ
　　||・ω・||　＜ﾃｨﾝ!!!!!
　　　|σ　|σ
　　　> 　>

山崎邦正ならマッチするのに

335:nobodyさん
05/10/05 17:39:44 gDrff9QN
requestとかcontrollerをAction中の複数のメソッドで使う時、
initializeでgetしておいてprivateなプロパティーとして持っておくのはｱﾘ？

336:nobodyさん
05/10/05 17:49:44
最近主流の複数画面で構成されてるサイトって
フレームワーク（的なもの）がなければ作れないよなぁ。
ベタ書きで作ってるサイトなんてあるんだろうか？

337:nobodyさん
05/10/05 22:36:32
>>336
複数画面で構成されてるサイトって ?

338:nobodyさん
05/10/05 22:44:00
>>337
ヘッダ-メイン-右サブ-左サブくらいにエリアが分かれてて
それぞれのエリアのコンテンツ構成が動的に変化するようなの。
ポータルとかニュースサイトのほとんどがこれ系だよね。

339:nobodyさん
05/10/06 01:04:30
別にフレームワークが必須だとは思わないけど。
フレームワークが一番効果を発揮するのは、何画面にも渡るアンケートフォームだろうね。
アンケートデータの持ち回りと、ヴァリデーションに応じて遷移先の画面が変わるから。

340:nobodyさん
05/10/06 01:17:22
>>338
別にベタ書きでも書けるけど、フレームワーク使ったほうが早いときもあるってだけの話だ罠。

>>335
Mojavi系の話だよね？毎回contextから取得するのがMojavi標準的くさいからﾅｼ。
ローカル変数にrequestとか入れるくらいまではｱﾘだと思うが。

例えばヘタに$this->request = "うんこ";とかやると他のメソッドに響くし。
その点では、PHPにfinalがあればMojaviの仕様も大分違ってたのではないかと想像。
少なくとも$this->context->getRequest()か$this->context->requestくらいにはなるんじゃないかな。
$this->requestまでなるかどうかは、何とも言えないがｗ

341:nobodyさん
05/10/06 06:29:57
>標準的くさいからﾅｼ。
久しぶりにその方言聞いた。なつかしいなー。

342:nobodyさん
05/10/06 13:06:02
URLﾘﾝｸ(www.glamenv-septzen.net)

和製フレームワーク追加

343:nobodyさん
05/10/06 13:07:29
仕事でMojavi使ってた人は今どうしてるんだろう
Agaviに流れたのか他に行ったのか

344:nobodyさん
05/10/06 15:47:14
>>339
データの持ち回りなんてセッションで十分だと思うのだが・・・・
いまだに俺はフレームワークの利点が分からない。

345:nobodyさん
05/10/06 19:53:34
>>342
名前似てるけど、俺は和製フレームワークはpokが一押し。

>>343
多分仕事で使ってた人は、少なからず手を加えてるので、
わざわざAgaviには流れてないんじゃないのかな？

>>344
自分一人で作ってたりする人はそうかもね。
「俺的フレームワーク」ってのを知らんうちに使ってたり。
まさか毎回1からなんて事はないでしょ？

346:nobodyさん
05/10/06 20:18:00
>>345
その pok ってのポインタきぼん

347:nobodyさん
05/10/06 20:24:05
URLﾘﾝｸ(www.geocities.jp)
ここのおかげでやっとDecoratorを理解した…
自分がﾊﾒﾊﾒされるテンプレートをあらかじめ指定しておけるんだね。
こりゃ便利だ。

348:345
05/10/06 21:31:38
>>346
URLﾘﾝｸ(cgi39.plala.or.jp)
S2Container.PHP5の人ね。
Seasarに関わってる人達を個人的にスゲー注目してる。
パフォーマンス的には？？って感じは否めないけど、
PHPでも結構やれるなって事がわかって良かった。
スゲー勉強になった。
S2Daoとかｽﾝｹﾞｰ期待してる。
俺の中では糞盛り上がってるんだけど、
MLとかｽﾝｹﾞｰ寂しいし、ひょっとしてめちゃくちゃ
ﾏｲﾅｰなのかなぁ・・・と心配になってきてる・・・。

349:nobodyさん
05/10/07 01:02:37
>>348
ありがとー

Seasar.PHP の ML は読んでるから名前は見ていた人だわ
S2Dao とかおれも期待しているんだけど
正直，きちんと追ってない人には活動が何してんのか見えなさすぎて，
それがマイナーっぽい原因になってるんだろうなーと思う

350:nobodyさん
05/10/07 04:58:48
フレームワークのウリとしてフォームの取り回しの簡便化がよく喧伝されるけど
俺はそこはあんまり重要じゃないなぁ。
そんなにしょっちゅう書く部分じゃないし、もともと単純な処理がほとんどだし。
デザインパターンに基づいた保守性の高さや、
見通しの良さの方が嬉しい。
簡単なことが簡単になっても、あんまり嬉しくないけど
複雑なものを単純にすることが出来たら、かなり嬉しい。

351:nobodyさん
05/10/07 05:03:27
privateやprotectedもないPHPでデザパタ重視はどうかと思う

352:nobodyさん
05/10/07 05:20:40
>>351
釣りなのか、PHP5 を知らないのか、どっち？

353:351
05/10/07 05:23:35
>352
釣りだ
350はデザパタがメインのレスじゃないだろ
まぁこれでも読んで考えてくれ
URLﾘﾝｸ(www.enpitu.ne.jp)
このスレとは全然関係ないんだけどさ

354:nobodyさん
05/10/07 08:06:14
フレームワークを使っているから、オブジェクト指向かというと、そういうわけでもないよな。
メンテナンス性を上げようと思えば、在り物のフレームワークを使うより、
自分なりにそのWEBアプリにあった仕組みを考えた方がメンテナンス性が上がる場合もあるだろうし、
メンテ担当の技量を考えて、クラスをいっさい使わないようにした方がメンテしやすい場合もあるだろう。

355:nobodyさん
05/10/07 13:12:01
forwardすることを前提としたactionでも、
url直接入力して直呼びすることもできるよね。
何か対策してる？

356:nobodyさん
05/10/07 13:37:39
してる

357:nobodyさん
05/10/07 13:56:25
いくつか方法は考えられそうだけど
どんな？

358:nobodyさん
05/10/07 14:04:28
requestにsetAttributeして飛び先actionで確認

359:nobodyさん
05/10/07 14:12:14
なるほど　thanks

360:nobodyさん
05/10/07 16:36:25
結局そういうことにrequestのattributeだとかuserのparameterを使うと、（コントローラの呼び出し等を除いて）実行されるコードの最初から最後までアクセス可能ってことになる。
そうなるとグローバル変数と変わらないんだよな。
もっと各状態の遷移ごとにアクセス制限のかかったデータの受け渡しができればいいんだけど、うまくいかないもんだ。

361:nobodyさん
05/10/07 17:27:56
セッション管理ではだめなのか？

362:nobodyさん
05/10/07 17:40:15
>>354
おいおい、そんな事させるからPHP使いはウンコのまんまなんだよ。
クラスを一切使ってねぇ～システムなんざ見る気しねぇ～よ。
つーかクラス使わずどうWebアプリ作ったらいいんだろ？すら思う。

363:nobodyさん
05/10/07 17:53:18
351の言ってる保守性は、アプリ自体の保守性
354が言ってるのはアプリ上に乗っかってくるデータやコマンドのメンテナンス性
で、フォーカスしてる層が違う感じがするな

364:nobodyさん
05/10/07 18:27:14
PHP4にはデストラクタないし、例外も投げれないから、クラスをネストさせたり、複雑に組み合わせたりはやりづらいよね。
スコープを明示できないからクラスを使わざるをえないけど、それじゃあクラスをクラスらしく使ったプログラミングとは言えない。
もっとも、WEBアプリというジャンル自体、オブジェクト指向のメリットがあまりないジャンルだと思うね。
どっちみちリクエストのたびにオブジェクト作り直しになるわけで、ユーザからの入力データもリクエストごとにフラットにしかこないわけで。使いどころがない。

365:nobodyさん
05/10/07 18:32:28
> もっとも、WEBアプリというジャンル自体、オブジェクト指向のメリットがあまりないジャンルだと思うね。

ふーん。

366:362
05/10/07 18:41:02
>>364
それは俺に対する回答だと思っていい？

クラス使ってる＝オブジェクト指向っていうのが間違ってると思うよ。
実際自分を顧みるに、オブジェクト指向を意識してクラスを使い始めたが、
オブジェクト指向にはならず、単に構造化になっただけだった。
だがそれだけでもかなり見通しが良くなったと思ったよ。

単にメンテ性だけを考えてもクラスを使用しているアプリと、
クラスを全く使用してないアプリとどっちがメンテし易いか？
って考えるとどっちだと思う？
俺はベタ書きで書かれたものを渡されて「メンテしろ」って言われたら、
とりあえず「作り直させてください」って言うな。

あと、クラスのネストってどういう事？

367:nobodyさん
05/10/07 23:01:26
DecoratorTemplate使う時で、
HTMLのヘッダ部での
外部JavaScriptファイルの読み込みとか
JavaScriptの初期値設定が必要な場合、どうしてる？
自分が「部分」になれるDecoratorは便利だけど
入れこみたい情報がソース中でバラける時、面倒くさいなぁ。

368:nobodyさん
05/10/07 23:14:07
別にクラスを使えばオブジェクト指向になるとは思わないよ。
それとフレームワークとオブジェクト指向とは関連性があるわけじゃないとも思う。
まあ、フレームワークにもよるけど。
これは言うまでもないと思うけど、オブジェクト指向を生かせるのはGUIのデスクトップアプリケーションとか。
WEBアプリの場合、リクエストの度にオブジェクトを作り直さないといけない。
特にPHPは永続化をどうするか？とか、言語機能が少ないとか、速度が落ちるとかっていう欠点もある。
まあ、これからはAjaxとかFlashとかで、高度なGUIを持ったWEBアプリが要求されるだろうから、そうなるとオブジェクト指向のメリットも出てくるかな。
けど、HTML自体があまりオブジェクト指向なプレゼン言語とは思えないんだよなあ。

369:nobodyさん
05/10/07 23:26:18
>>368
フレームワークとオブジェクト指向とは関連性があるわけじゃないとも思う

って関連ありまくりじゃん。
OOのエッセンスが分かちがたい程たっぷり入ってると思うよ。
OOを使わずともライブラリ集は作れるだろうが、
フレームワークは作りにくいだろう。

370:nobodyさん
05/10/08 00:07:12
>>368
今時「PHPでOOPすると性能が落ちる」とか言ってるのは時代錯誤もいいとこ。

371:367
05/10/08 01:39:24
ViewHelperで解決した(゜д゜)

372:nobodyさん
05/10/08 01:55:47
デストラクタもないのにオブジェクト指向ってありえるんだろうか？

373:nobodyさん
05/10/08 02:24:56
なんだこの掃き溜めは

374:nobodyさん
05/10/08 02:26:59
デストラクタがないとオブジェクト指向なプログラミングができない、
という思考回路が判らない。言語仕様に捉われすぎてる悪寒。

375:nobodyさん
05/10/08 02:28:24
ありだと思うな。
Cでもオブジェクト指向でまとめられたライブラリやツールキットは山ほどあるし。

オブジェクト指向プログラミング自体はべつに大抵の言語で可能だとおもう。
たしかにPHPはオブジェクト指向言語として設計されたわけじゃないが、
これとPHPでオブジェクト指向プログラミングをする事は矛盾しないだろう。

376:nobodyさん
05/10/08 02:45:50
てか5にはデストラクタもあるよ。
でもウェブアプリでデストラクタを使う機会はあんまりないだろ。

377:nobodyさん
05/10/08 05:08:37
>>372
あるよ

378:nobodyさん
05/10/08 05:09:53
>>370
時代錯誤というより、単に知識が乏しいだけだと思う。

379:nobodyさん
05/10/08 05:32:22
このスレでPHPによるオブジェクト指向プログラミングを否定している
連中は、オブジェクト指向じゃなくてC++ or Java指向になってるんじゃないか？
rubyもデストラクタは持ってないしな(GCがあるからだけど)。

380:nobodyさん
05/10/08 06:07:15
確かにウェブアプリじゃデストラクタなくても、なんとかなる。どうせ1回こっきりでプロセスごと終了するんだから。
そうすると、こったオブジェクト作ってもしょうがないじゃん。シングルトンとか、ウェブアプリでどれくらい意味あるのか。

381:nobodyさん
05/10/08 07:48:43
>>380
SingletonはDB接続に関するクラスで使ってるな俺は。
スゲー便利だしすっきりするなぁって思ったね。
要は使い方によるかなと。

382:nobodyさん
05/10/08 07:56:41
ほっといてやれよ。

383:nobodyさん
05/10/08 08:43:12
>>381
１回のアクセスでオブジェクトが全部ご破算になるWebアプリでシングルトンの意味はある？

$_db_ = new MyDB();
function getDB() {
global $_db_;
return $_db_;
}
:
:
//実際使う場所
$db = getDB();

これでいいんじゃない？

384:nobodyさん
05/10/08 09:07:34
>>383
グローバルオブジェクトを利用したSingletonの実装の一形態だろそれ
いいんじゃない？と言われりゃそうですねと言うしかないな
Java厨って実装から何から全部Javaと一緒じゃないと否定したがるのがうざいな

385:nobodyさん
05/10/08 09:16:29
>>383
意味が無いと思ったら使わなければいいだけの話じゃん

386:nobodyさん
05/10/08 09:45:38
PHP5にはデストラクタあるだろ。

387:nobodyさん
05/10/08 10:47:02
あるって何回も書かれてるってw

388:nobodyさん
05/10/08 10:56:20
383のやり方だとグローバル空間が汚れるじゃん。
_を使うのはやっぱり苦肉の策だし、クラシックな作法だろう。

389:nobodyさん
05/10/08 11:00:17
おれはsingltonならstaticで書きます。

390:nobodyさん
05/10/08 14:36:34
DB_DataObjectなんかは>>383みたいな感じだね

Java厨というよりJavaを意識しすぎたPHPユーザー、みたいな印象を受ける
Javaを意識するあまり、「PHPじゃないと出来ないことをしないといけない」みたいな傾向ってあったと思う
最近はその対象がRubyに移ってきたみたいだけど

391:nobodyさん
05/10/08 16:18:59
俺はDB接続部分をSingletonにして、各テーブルに発行するSQL文などを集めたクラス
がgetInstanceするって感じに使ってるけど、おかしいのかな？
各テーブルというと語弊があるかな。ある程度のテーブルを纏めたクラス。
JOINする場合（というかJOINしない場合が珍しいけど）は基となるテーブルのクラスに入れる。
$a = Atables();
$b = Btables();
print_r($a->getSelect());
print_r($b->getSelect());
って感じで。
全然スマートじゃないなぁとは思うけど、
DB周りはどうやったらスマートになるのか
全然わからん。解説サイトではロジック部（？）とSQL発行部
が混じっているが、個人的にそれはすごい抵抗があるし。
誰かご教授下さい・・・。

あ、今月のPHPプログラマーズマガジン無料だって！
JPSPAN扱ってるね。あれ@ITかなんかで廣川さんが
解説してて、それ以来使ってるけど、あれ使ってる人って
聞いたことないから不安になってた。
スレ違い＆長文すまん。

392:nobodyさん
05/10/08 16:42:29
OOにデストラクタを重視する奴は意味が分からないな
前時代の遺物的存在じゃん
後片付けは言語側で勝手にやってくれる方が今風だし、ｷﾚｲだ

393:nobodyさん
05/10/08 17:14:13
C++でOOP入りした人は感覚的に染み付いていて、抵抗あるんじゃないかな。
オレも昔はそうだった。ruby, PHP, C#で、すっかり骨抜き？にされたけど。
なんつーか最初の頃は堕落した感じがしたもんだ。
（良い悪いとかじゃんくて、楽チン→堕落、みたいな妙な感覚）

394:nobodyさん
05/10/08 17:52:40
お、お前ら・・・お前ら何言ってんだ？？
お前らの会話の内容がサッパリ分からんぞ、DQNな漏れは。

もうね、難しいとか難しくないとかいうレベルじゃない。
何の予備知識もないスワヒリ語を聞いてる感じ。

395:nobodyさん
05/10/08 18:06:12
>>394
それはDQNだからじゃなくて単にオブジェクト指向開発用語を知らないだけだと思う
つまりそれを勉強すればこの会話の意味はすっかり解るだろうし
勉強して損ないものなのでぜひ習得してみるべし

396:nobodyさん
05/10/08 18:38:45
>>395
勉強できる Web をうpきぼん。

397:nobodyさん
05/10/08 19:05:01
>>392
勝手に行うのはメモリ開放だけだろ。
さらにPHPはfinally構文がない。

398:nobodyさん
05/10/08 21:14:56
finally構文ってオーバーライドを禁止するfinalのことか？
finalならPHP5にあるが。

399:nobodyさん
05/10/08 21:17:47
>>398
例外処理のfinallyでしょ。
Javaなら以下のように書けるけど、PHPではfinallyが書けないので
リソースの破棄を行いたい場合などに二度手間になることがある。

try {
　例外の起こりそうな処理
} catch (Exception e) {
　例外発生時の処理
} finally {
　例外が起きても起きなくても実行したい処理
}

400:383
05/10/08 22:26:28
>>390
> Java厨というよりJavaを意識しすぎたPHPユーザー、みたいな印象を受ける

JavaはHelloWorldくらいしか書いたことないな。
俺のよくいじる言語はSmalltalk, Ruby, PHP, JavaScriptだよ。
あとSchemeも好きだな。

わざわざclass定義してstatic変数用意して２つもメソッド書いて、
結局>>383のたった6行でできることをかえって複雑にするのはアホらしい
ってことだ。

401:nobodyさん
05/10/08 22:41:27
まあ、「Singletonって書きたいだけちゃうんか」というコードが多い
という気はする。

402:nobodyさん
05/10/08 22:43:38
>>309
>>他にもデメリットとして、smartyのようなテンプレートエンジンを使うと実行速度がぐっと下がるし、

これはウソでしょ。

403:nobodyさん
05/10/08 22:45:32
Singletonパターンってイディオムみたいな感じだよね。
確かに無理して本に乗ってる書き方通りにしなくても良いとは思う。
Javaみたいにマルチスレッド環境になることもないし。

404:nobodyさん
05/10/08 23:03:48
383の書き方だと、呼び出し側のコードを見ただけでは
それがSingletonなのかどうかは判別できないじゃん。
確かに伝統的な書き方は記述が面倒だけど、
一人の思考ではなかなか太刀打ちできない強度があるもんだよ。
たくさんの頭脳を経た思考の蓄積や時間による淘汰は馬鹿に出来ない。

405:nobodyさん
05/10/09 00:09:28
>>400
わざわざ冗長に見える記述をするのはそれなりの理由があるからで、
それが感じられないならオブジェクト指向自体が冗長だろう
ていうかSmalltalkとかRubyのほうがよりオブジェクト指向が強いと思うのだが

406:nobodyさん
05/10/09 00:13:58
冗長って何？

407:nobodyさん
05/10/09 00:26:12
>>406
君は初心者向けの本とかをたくさん読んできなさい
フレームワークスレはまだ早い

408:nobodyさん
05/10/09 01:17:58
>>400
class aClass {
function &singlton(){
static $me;
if(!is_object($me)) $me =& new aClass;
return $me;
}
}

$instance =& aClass::singlton();

これがそんなに複雑かな?
わざわざgetDB()とか$_db_とかというのをグローバルな名前空間に
つくる方が複雑化を招く気がする。

実際に作る時はこのままではなんとなく気持ち悪くてスタティックな
コールであることを保証したりしちゃうから、そういうときはたしかにphp4で
ちょっと損した気分になるね。

409:nobodyさん
05/10/09 03:49:12
PHPでのシングルトンには、「リソースを効率よく使うため」ではなくて
「意図を表すコーディング」としての効果を期待しろ、ということで。

410:nobodyさん
05/10/09 07:15:34
>>400
なんか実用的なプログラム書いた事無くて、頭の中で屁理屈こねくり回してるって印象を受けるな～

411:nobodyさん
05/10/09 07:19:12
PHPに限らずアクセスレベルなんかも、
実際に使っちゃうリスクへのヘッジというよりも
意図を埋め込む意味合いの方が強いよね。

412:nobodyさん
05/10/09 11:23:06
意図なんてコメントとして書いておけばよい。

413:nobodyさん
05/10/09 12:57:50
>400
そもそもシングルトンで重要なのは、コンストラクタを private とかにして、
オブジェクトの生成が出来る箇所を限定することの方だろ。

414:nobodyさん
05/10/09 14:48:09
↓これはシングルトン？

/**
* シングルトンとして使ってください（オブジェクトは1度だけしか生成しないでください）。
*/
class Example
{
　：
}

415:nobodyさん
05/10/09 14:58:42
プログラムは改変されていくものだから、
コメントがいつの間にか嘘の説明にならないよう、
むしろ少なめ推奨がモダンな作法。
独善的持論をぶってる奴はもう少し勉強しれ。

416:nobodyさん
05/10/09 15:04:08
DB鯖がセッション用と顧客データ用と別だったりとかさー
DBオブジェクト複数接続先で使いたい時とかって割と無い？

417:nobodyさん
05/10/09 15:06:04
↑解かりづらいか、「DBオブジェクトを接続先別に複数生成したい時」と言い換え

418:nobodyさん
05/10/09 15:18:56
俺はSingletonなDBオブジェクトにコネクションコンテナを持たせてる

419:nobodyさん
05/10/09 16:51:24
>>415もまた独善的持論なわけだが。

420:nobodyさん
05/10/09 16:53:47
ﾊｲﾊｲそうだね

421:nobodyさん
05/10/09 18:16:42
あー、415のせいで荒れ始めただろ……責任とって下さい、415

422:nobodyさん
05/10/09 18:49:57
何で糞ｶﾞｷがこんなｽﾚに迷い込んできたんだ…。

423:nobodyさん
05/10/09 18:52:26 j3jR0Qvz
ままー　おなかすいたー

424:nobodyさん
05/10/09 18:56:57
>>415
>プログラムは改変されていくものだから、
まあ、その通り。
>コメントがいつの間にか嘘の説明にならないよう、
確かに気をつけないと。
>むしろ少なめ推奨がモダンな作法。
いきなり妄想が入ってきました。
>独善的持論をぶってる奴はもう少し勉強しれ。
独善的持論乙

425:nobodyさん
05/10/09 19:30:17
>>424
だから勉強してから書けって言ってるだろ？
お前の浅薄な意見なんて何の参考にもならねーんだよ。

426:nobodyさん
05/10/09 19:38:21 QrQMlw6M
ソースのコメントを少なめ推奨している、モダンな作法とやらのポインタくれ。

427:nobodyさん
05/10/09 19:38:25
お子ちゃまたちは
XP（エクストリーム・プログラミング）についてなど
調べてみようね。
最近よく出版されてる軽めのプログラミング読本も
結構参考になるよ。

428:nobodyさん
05/10/09 19:39:39
底が知れたなｗ
一瞬俺の知らない技術体系が発生してるのかとおもた

429:nobodyさん
05/10/09 19:45:20
XPってコメント少なめ推奨してるのか？

430:nobodyさん
05/10/09 19:50:40
コメントなきゃ判らんコードはリファクタリング候補ってこと
量が少ないほうがいいとかモダンとか言うのはオカルトつーか誤認

431:nobodyさん
05/10/09 19:56:38
>>430
同じことを簡単に言ってるだけだろ。
まあケチつけたいだけの奴は
Singletonをコメントで実現しとけばいいんじゃねーの？

432:nobodyさん
05/10/09 20:03:13
全く違うよ。XPのレトリックが読めてない典型ﾜﾅﾋﾞｰ君じゃん。
コードとの差異が出ないようにコメントを最小化する、なんてのは
アジャイルでもなんでもないし、リファクタリングしないことが前提の
固定的な開発思想でしょ。

433:nobodyさん
05/10/09 20:07:19
ここはフレームワークについて語るスレですよ。OOPの話は↓でしない？
PHPでオブジェクト指向プログラミング
ｽﾚﾘﾝｸ(php板)

434:nobodyさん
05/10/09 20:18:50
よしフレームワークにおけるアノテーションやAOPの意義について考えようぜｗ

435:nobodyさん
05/10/09 20:29:41
>>432
あー、お前の言うことにも一理あるね。
というか、お前が俺の言葉をどのように捉えたのかは理解したよ。
言葉のツラだけ捉えればまさにオカルトという言葉が相応しいかもしれない。
世の中には言葉をそういう風に使って金儲けや愚かな事をする輩が溢れているから
ダイレクトにそう捉えられたのも無理はないと思う。
だけど俺が言いたいのはそういうことじゃないんだよ。
なんか議論がつまらない方向に発展していきそうなのでこのへんで切り上げますが。

436:nobodyさん
05/10/09 20:35:02
>>435
上の流れがあるから指摘の意義は判ってる奴は普通に判ってるだろ
幼稚な煽りで見れたものじゃないがな

437:nobodyさん
05/10/09 22:21:08
>>434
PHPでリフレクションを利用したコメントアノテーションはちょっと興味ある
言語仕様になくても無理矢理実現できるのがPHPらしいというかなんと言うか

438:nobodyさん
05/10/09 22:33:52
まあ今のとこお守りみたいなもんでコメントと大差ないけどね

439:nobodyさん
05/10/09 23:00:25
>>434
XPはコメントとかコード外のメタデータや宣言を否定するわけじゃないっつの
それがリファクタを困難にするとも言ってない
読めるコードを書けっていう当たり前のことが言いたいだけなんです

440:nobodyさん
05/10/09 23:22:19
みんな理屈はいいから結論を書いてくれよ
>>414はアリ？ナシ？

441:nobodyさん
05/10/09 23:24:45
お子ちゃまは寝る時間ですよ

442:nobodyさん
05/10/09 23:40:49
オフィシャルではアノテーション導入する気はないみたいだなあ。
やっぱりコンパイラが対応してくれないと…フレームワークレベルでは実効力に欠ける。
Maple以外でDI+AOPなフレームワークってないのかな?

443:nobodyさん
05/10/10 00:43:37
>>440
本当に理屈は要らないんだな？

ナシ。

444:nobodyさん
05/10/10 02:00:10
フレームワークのﾒﾝﾃﾅが提供してるサンプルは
どれもこれもシンプル過ぎていまいち参考にならないなぁ
もっと踏み込んだサンプルをﾁﾎﾞﾝﾇ

445:nobodyさん
05/10/10 07:29:44
議論を読んでない俺が思うのは、開発手法の議論は他のスレでやってくれということだ。
つーかガチガチのクラス使いたいならJavaでやれ。
PHPでやらなきゃならん制約があるなら新スレでも立てるろや。

446:nobodyさん
05/10/10 07:35:31
俺が思うのは
フレームワークの開発がどれも停滞し過ぎということだ。

447:nobodyさん
05/10/10 09:25:29
YAMLってJSONみたいな物？

448:nobodyさん
05/10/10 09:35:59
>>442
上にも出てたけどpok。
実務レベルでどうか知らんけど、勉強用にはとても良かった。

>>446
最近はMapleが活発になってきたんじゃないかな？

449:nobodyさん
05/10/10 10:57:46
MapleってM3のDecoratorみたいな
CompositeViewを実現する機構がなくない？
そこが俺的には痛いｯｽ

450:nobodyさん
05/10/10 11:04:05
>>447
違うね。

451:nobodyさん
05/10/10 11:09:10
>>450
どっちも汎用の構造化データ記法でしょ？
同じような物じゃないの？

452:nobodyさん
05/10/10 11:45:47
>>451
JSON と XML が同じようなものである程度には，
JSON と YAML は同じようなものだとは思うが，
一般的には「違うもの」として捉えられていると思う．

てゆーかJSONって形式としちゃ汎用とはいえ
例えばPHP→Javaのデータ転送にJSON形式使う奴なんていないんじゃないかと……

453:nobodyさん
05/10/10 11:50:50
構造をあらわすっていう超大雑把な括りに何か意味あんの?

454:nobodyさん
05/10/10 11:55:22
>>452
だがJSONはそれでいい

455:nobodyさん
05/10/10 12:03:23
>>453
意味っていうかプロトコルの一種だろ
やりとりのための約束ごととして決めておく。
絶対的な必然性はなかなかありえないから
「どっちでもいい」に落ち着きそうな気はする。

456:nobodyさん
05/10/10 13:49:15
強いて言えば
　人間に読みやすく設計されてるのがYAML
　JavaScriptに読みやすく設計されてるのがJSON
　誰もが読みにくい代わりに高機能なのがXML
って感じかねぇ？

457:nobodyさん
05/10/10 13:54:12
確かにYAMLは人が見やすいなぁ
中庸っぽさがPHPと似てるかも
JSONも嫌いじゃないけど

458:nobodyさん
05/10/10 14:37:54
JSONは専らJavaScriptと連携するときに使う印象。

ところでMapleはPHP5には対応しないのかな？
Mapleの目指す方向からしてPHP5で書いた方がずっと楽＆適してるように思うんだけど。

459:nobodyさん
05/10/10 14:44:41
前から4で続けると明言してる
やったことないけど、5じゃ動かんの？

460:nobodyさん
05/10/10 17:11:33
っていうかつまらん議論してるならコンピュータなんて捨てちまえ！！！
別に無くてもあまり生活に困らないぞ。

461:nobodyさん
05/10/10 17:17:24
>>460
この議論がつまらんと思うなら460にはそれが良かったんだろうな
幸せな人生を歩んでくれ

462:nobodyさん
05/10/10 19:13:07
Mapleって4なんだ。
プレゼンテーション層をActionだけにしたところは共感してるんだけど
機能的にはまだMojavi系の方が厚いっぽい。

463:nobodyさん
05/10/10 19:28:10
DIってのは簡単に言うと
器だけおいておくとフレームワークが勝手にオブジェクトを
放り込んでくれるｳﾝｺﾎｳﾘﾅｹﾞ!( ﾟ∀ﾟ)つ=====o
みたいなことを言ってるのかな？

464:nobodyさん
05/10/10 19:38:53 +MnfvWOk
>>463
そんな感じかな。

465:nobodyさん
05/10/10 21:11:32
ｳﾝｺﾎｳﾘﾅｹﾞ!( ﾟ∀ﾟ)つ=====oられるために
Mapleは設定ファイルを用意、
guessworkはプロパティーを用意すると。
Actionだけを見てざっと把握できるから
その点ではguessworkがいいかな…。

466:nobodyさん
05/10/11 12:40:17
勉強してる余裕ないから、いまだにguessworkしか使えない。(´･ω･`)ｼｮﾎﾞｰﾝ

467:nobodyさん
05/10/11 18:13:27
Mojaviで
属性をメソッドから返す作法が面倒くせーと思ってたけど（プロパティー用意で良くね？と）
内部条件によって属性を変えられるメリットがあるんだな。
Mojaviは知るほどに、「よく考えられているなー」という部分がある。

468:nobodyさん
05/10/11 19:47:53 G45STU1Q
>>467
Mojaviだからではなくて、ただの情報隠蔽だろ。

469:nobodyさん
05/10/11 20:54:40
mojavi4って一応作ってるんだな
ソース見る限りでは、完成には程遠いけど

470:nobodyさん
05/10/11 21:58:17
>>468
それもあるだろうね。
ただそれだけじゃなく、コードを書くことを前提としてると思うよ。

471:nobodyさん
05/10/11 23:15:49
>>470
？？
属性をセッターゲッターで操るのはMojavi独自の実装ではなくて定石だろ？

472:nobodyさん
05/10/11 23:33:22
だな。俺もコードを書く時に「ゲッターロボ GO-!!」とか[セッターロボ GO-!!」とか言いながらやってるよ。

473:nobodyさん
05/10/11 23:34:34
単なるセッターゲッターじゃなくて
Actionにとっての設定的な項目を
メソッドの形で実装して返すのがMojavi流じゃん。
しかもプロパティーに対するアクセサじゃないから
セッターゲッターじゃないし。
設定ファイルで済むようなことを
なんでメソッド書きまでしなきゃいけないのかと疑問だったのだが、
確かに利はあるな、と思ったということ。

474:nobodyさん
05/10/11 23:35:27
利→理だね

475:nobodyさん
05/10/12 00:49:34
>>473
セッターゲッターの存在意義わかってる？

476:nobodyさん
05/10/12 02:03:55
>>475
いや当然普通に分かってるけど…。
なんかいまいち伝わらないみたいだな。

477:nobodyさん
05/10/12 10:36:29
>>476
RubyとかRailsの人のよく言う言語重要てやつのことかね。
設定ファイルなどに頼るな、言語で一回だけ書きゃいいのだ。というあの信条。

うちではJava系のひとのStrutsアレルギーでMojaviは使っていないのだけれど。

478:nobodyさん
05/10/12 15:07:00
>>181
遅レスだが
firefoxならOSXでも使えるんだね
昔はMacなんて置いてけぼりだったのに便利な時代になったなぁ

479:nobodyさん
05/10/12 18:11:38
オブジェクト指向的にSQLを組み立てられるソリューションをどなたか知りませんか？
分散DBにしたいので、DBアクセス部分はこっちで書こうと思っています。
SQLのみを書いて欲しいのですが、それに機能を限定したものが
なかなか見つかりません。

480:nobodyさん
05/10/12 23:10:35
PHPで最適なフレームワークはなに？

481:nobodyさん
05/10/12 23:23:10
一長一短で、定番はないよ。

482:nobodyさん
05/10/13 09:49:24
長所短所を比較しているところってないですか？

483:nobodyさん
05/10/14 04:53:33
>>476
いやいやわかってないってｗ

484:nobodyさん
05/10/14 07:20:42
？
分からないのはむしろ君の頭の中だが…。
そもそもがセッターゲッターの話じゃないわけで。
Mojaviを実際に使ったことあるかい？

485:nobodyさん
05/10/14 07:52:01
>>475と>>483はほっとけ
スルーしてりゃ消えるでしょ

486:nobodyさん
05/10/14 11:51:40
この板の人達はスルーすることを知らない

487:nobodyさん
05/10/14 13:55:39
技術者だから基本まじめなんだよ。
だいたいフレームワークスレで煽る意味が分からない…。

488:nobodyさん
05/10/15 13:24:45
>>487
煽る→怒った奴の中に自称女が現れる→女と証明してみろﾌﾞｻｲｺと煽る
→怒った女は、ｵｯﾊﾟｲやﾊﾟﾝﾂ写真をUP→みんな素人エロ画像にﾏｯﾀﾘ

489:nobodyさん
05/10/15 16:04:32
>>488
うむ、とても平和な流れだ。
その流れを、このスレに当てはめるとどうなるんだろう。

490:nobodyさん
05/10/15 23:57:37
ここPHPのフレームワークスレだよね。。。

いま作ってるんだけど、需要あるのかなぁ。

491:nobodyさん
05/10/16 16:16:44
>>490
既存のフレームワークより優れた点があるのなら

492:nobodyさん
05/10/16 16:30:50
既存フレームワークも大分広まってるから
あまりにも独自だと、
学習コストが比較的高くなって普及しないかもね。
かなり戦略的でないとこれから普及されるのは難しいと思う。

493:nobodyさん
05/10/17 01:25:22
>>492
今ある奴で開発がとまり気味のものとか、今あるものをベースに
進化させてくれるひとがいたら結構いいと思うけどな

494:nobodyさん
05/10/17 01:40:18
またforkふえるのか！
agaviかmojavi4に統一しようよもう。

495:490
05/10/19 19:41:56
どうも490です。

今作成してるのはHTMLﾃﾝﾌﾟﾚｰﾄをベースにF/W的なことをやろうって
感じで実装しています。

機能としてはﾃﾝﾌﾟﾚｰﾄ＞PHPの置き換えのオーバーヘッドを少なくするために
中間コードをキャッシュさせる機構や、携帯電話の絵文字変換（ｷｬﾘｱ相互変換）、
標準で使えるDBラッパー（MySQL.PostgreSQL,Oracle,SQLite)等です。

基本的には汎用クラスで動くように作ってあります。
といっても画面に出力するためにコントローラが必要ですが。

プログラム自体の実装は１クラス１モジュール扱いで、ﾃﾝﾌﾟﾚｰﾄから呼び出す
メソッドがコントロールメソッドでその中で他のメソッドを呼び出すのが
モデルメソッドみたいな感じです。んで、HTMLﾃﾝﾌﾟﾚｰﾄがViewです。
たぶんMVC的構造になっています。

クラス実装する前のスケルトン自動生成機能なんかもつけようかと
思ってます。

ﾃﾝﾌﾟﾚｰﾄ中のタグ類は専用タグを使い
条件設定(ifに相当するorやandも可とその逆の動作)タグや、
プログラムに渡すオプション値タグ、繰り返し（ループ）タグ、
絵文字変換タグなんかを組み合わせてViewを書くといった感じです。

496:nobodyさん
05/10/19 19:59:15
>>495
DBラッパーはPDO以上なん？
ＨＴＭＬテンプレートはSmarty以上なん？

497:nobodyさん
05/10/19 21:33:26
今からだとDB抽象クラスはPDOで十分だと思うけど
テンプレートは Smarty 以上である必要なんてないじゃん。
（そもそも何をもって「Smarty以上」とするのか）
Smarty は高機能で普及もしてるけど個人的には良いとは思わないし。

テンプレートエンジンとフレームワークが密に連携するってのも面白いと思うよ。
携帯絵文字は Vodafone のエスケープシーケンス使う奴がウザいね。
DoCoMo や EZweb の絵文字は比較的扱いやすいんだけど。

498:nobodyさん
05/10/19 22:21:53
絵文字変換なんていいんじゃない？
そういうアプローチのフレームワークはまだないし

499:nobodyさん
05/10/19 22:58:41
>>498
絵文字変換だけならフィルターとか掛けてやるだけじゃん

500:nobodyさん
05/10/19 23:18:29
>>499
絵文字はSJISでテンプレートとかDBはEUCJP推奨だから、特にsmarty使うとき色々面倒

501:nobodyさん
05/10/19 23:35:39
iMode/EZwebの絵文字はSJISの私用領域を使ってて、PHPならSJIS-win/eucJP-win/UTF-8 で相互変換可能。
端末が表示できるのはSJIS(-win)だけだけど、ちゃんと変換してやれば途中の処理を eucJP-win/UTF-8 でやっても大丈夫。
あと最近はUTF-8でも（EUCは知らない）携帯キャリアのゲートウェイがSJISに直してくれるっぽい。

とりあえず基本的な絵文字が見られればいいってことなら、EZweb/Vodafoneの絵文字を
iModeの絵文字に変換しておくのがいちばん簡単かな？
iMode絵文字なら他のキャリアでもゲートウェイが端末に応じた絵文字に変換してくれるし。

502:nobodyさん
05/10/20 03:09:08
>>500
smartyを使いこなせていない予感。

503:500
05/10/20 03:16:14
>>502
むしろ使うためにsmartyをハックした

504:nobodyさん
05/10/20 11:28:03
>>503
スーパーハッカーこわー

505:nobodyさん
05/10/20 20:20:44
絵文字変換なんかまさにフィルターの仕事。

506:nobodyさん
05/10/22 00:38:22
ドコモの絵文字をDBに入れるときどうすればいいの？
EUCに変換したら消えちゃうよね？
DBをSJISにするの？

507:nobodyさん
05/10/22 02:52:18
URLﾘﾝｸ(itpro.nikkeibp.co.jp)

Zendが「Zend PHP Framework」なるものを作ってるとのこと。
最終的にはこれに収斂されるのかな。

508:nobodyさん
05/10/22 10:02:06
>>506
絵文字を入れたいタプルをBLOB型に設定してBINARYフラグを有効にする

509:nobodyさん
05/10/22 14:03:08
>>508
そんなことしてオーバーヘッド大丈夫なの？
少量ならそりゃ大丈夫だろうけど、全文検査とかどうよ？
postgresqlのsjisパッチあてるとかは？

510:nobodyさん
05/10/22 18:35:14
>>506
俺は文字参照に変換してる。

511:nobodyさん
05/10/22 20:53:13
CakePHPのソースを漫然と眺めていたんだけど、その語尾の特殊変化の設定ファイルに
penisとtestisがあったよ。これで下品なソースでも安心だね。アダルトサイトにも最適。

でもこれいいわ。なんて言うか、流れに身を任せればとても楽。コンパクトだから見通しもいい。
それにやっぱり死にかけのプロジェクトよりも生きのいい方がいいしね。

512:nobodyさん
05/10/23 02:30:29
>>511
>語尾の特殊変化の設定ファイル
なにそれ

513:nobodyさん
05/10/23 02:34:17
>>510
？xA0; みたいなやつ？
他キャリアのつもみんなドコモのやつに置き換えるの？

てか、フレームワークすれでこんなこと聞いてすまん。

514:nobodyさん
05/10/23 06:55:11
cake

515:nobodyさん
05/10/23 16:59:56
>>512
cakeはRails系なので、規約は設定に勝るっていう哲学で作られてる。
たとえば、Userというモデルが対応するテーブルはUsers決め打ちになる。
だから、特殊な場合の変化形を自前でもっとく必要がある。

もちろん、大抵の規約は上書きすることができるけど、それだとcakeの意味がないしね。

516:nobodyさん
05/10/23 20:58:51
>>507
JavaのJakartaプロジェクトみたいなものかな。
今後の標準になるようなものを作って欲しいなぁ。

次ページ