PHPでオブジェクト指向プログラミング
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2005/04/17(日) 16:55:57ID:iM4mgYnJPHPによるOOPについて語りましょう。
0312nobodyさん
2005/06/19(日) 11:27:33ID:???よくPHPでｶﾞﾝｶﾞﾙな・・・・・・
ちなみにListってどう実装してんの？
class Node { private $data, $next; }
で$nextに参照いれるとか？
class List { private $array; }
だったりしてｗ
0313nobodyさん
2005/06/19(日) 12:08:25ID:???いや、逆にOO厨がPHPなんて全然OOじゃない！とか
言い出しそうなので先手を打っといたって感じがする
（あるいは既に叩かれたので書き足したとか）。
C++をOOPLじゃないと攻撃するPHPユーザは見たことないが、
PHPやC++をOOPLじゃないと攻撃するOO厨は沢山いるんじゃん？
print "abc";
こういうのもOOじゃないって怒る人いるよね。
"abc"->print();
すべからくこうすべきだと。
0315nobodyさん
2005/06/19(日) 13:28:36ID:9u3ddzIOPOSTのチェックはifの連続以外になんかないですか
0316nobodyさん
2005/06/19(日) 13:34:42ID:???0317nobodyさん
2005/06/19(日) 13:38:10ID:???名前がありませんとか長すぎますみたいなやつ
if(! $name) {...}
else($name > 100){...}
みたいな
0318nobodyさん
2005/06/19(日) 13:48:42ID:???まあ俺だったら空欄系は空欄系で、文字列長さ系は文字列長さ系で、不正文字系は不正文字系でまとめるけど。
どうでもいいけどそのコードテキトー杉だなｗ
0320nobodyさん
2005/06/19(日) 14:15:23ID:???function strLengthCheck ($str, $min, $max) {
if(strlen($data) < $min and strlen($data) > $max) {
return "長さが変だよ";
} else {
return 0;
}
}
こういうことにしても結局同じになるんだよなー
0321nobodyさん
2005/06/19(日) 15:04:48ID:???>>319
つ http://www.planewave.org/translations/quickform/html_quickform.html
ちと重いし使いにくいけどな。
こういうの参考にして自分なりにパッケージ作ってもいいし。
0322nobodyさん
2005/06/19(日) 15:31:14ID:???アドホックな使い方が出来るのがPHPの良さだし、
雑種的なものとして成長してきたから、
「必ずOOPを推奨するものでは決してありません」と言いたいのでは？
敷居の広さをアピールしているように俺は受け取ったが。
0323nobodyさん
2005/06/19(日) 15:41:22ID:???$length_limits = array(
'name' => array(5, 10),
'message' => array(0, 500),
...); // この部分DBやファイルに入れといて取得してもいいし。
foreach ($length_limits as $key => $limits)
{
list($min, $max) = $limits;
$len = strlen($_POST[$key];
if ($len < $min or $len > $max)
// 長さが変だよ
else
// 変じゃないよ
}
っていうかそんなに面倒だと思ったことないけどな。
0324nobodyさん
2005/06/19(日) 15:44:30ID:???0325nobodyさん
2005/06/19(日) 15:51:46ID:???0326nobodyさん
2005/06/19(日) 15:58:40ID:???一理あるな。
PHPはOOPでもいけるけど、使わなくてもいけるってのは大きな利点。
俺的にPHP5のOOはけっこうｲｲと思ってる。
中にはPHPはプリミティブ型がオブジェクトでないとか言う奴いそうだけど、そこまで不便でもないし。
まー型なし言語って意味で仲間のJavaScriptみたいなプリミティブ型の実装もけっこう好きだけど。
ガッチガチのOOしたいならOOPLを選べばいい。
0327nobodyさん
2005/06/19(日) 16:44:14ID:???同意。
>>325
チェックの条件を正規化してないから。でしょ多分。
んでも俺はクラス化してるけど、パスワードチェックの部分なんかはかなりif文並んでるよ。
※うちで必ずやる客が入力したパスワード検証
・英文字＋αになっているか（英文字だけ、制御文字、バイナリ、日本語コードなどはNG）
・0123とかabcdとかasdfgとかqwertyとかが含まれていないか
・同じ文字が4つ以上連続していないか
・ユーザー名と同じでないか
・ユーザー名の逆順と同じでないか
・メールアドレスの左側と同じでないか
・メールアドレスの左側の逆順と（略
： めんどくさいのでやめ
て感じで推測されやすそうなのは全部弾き飛ばしてる。大きいシステムになると
ローマ字＋英語のdic使って単語の組は弾いたりするよ。
0328nobodyさん
2005/06/19(日) 17:13:00ID:???そこにあげた項目ほとんどが結局はpreg_matchの類だろ。
だったらパターンだけ配列にいれてforeachで回せばifなんか激減だろ。
あ、いや、>>327に言ってるわけじゃなくて。>>324がifじゃ嫌とかいう話だったから。
>>327はifが並んでても気にしてないみたいだから好きなだけ並べてください。
0329nobodyさん
2005/06/19(日) 19:13:02ID:???文字数のmax・minチェックは？
必須チェックもあるだろ？
日付の妥当性チェックなんてのもある。
あんたが言うほど単純なものじゃないんだよ。
0330nobodyさん
2005/06/19(日) 19:20:24ID:???0332328
2005/06/20(月) 03:52:16ID:???パスワードのチェックを一生懸命頑張ってるのはわかったよ。
そこまでやると利用者にとってはﾑｶつくだけの機能だけどなｗ
ちなみに俺はifの話をしてるだけなので。
ifは３回で済むやんその部分・・・
と言ってみる。
ちなみにもう一回言うけど、あんたがifを並べて書く分には文句ない。
>>315から始まったifダラダラが嫌な方々に対しての話だから。
それとも>>329=>>327=>>324=>>320=>>319=>>317=>>315だった？
それだったら必死こくのもうなずけるｗ
0333nobodyさん
2005/06/20(月) 07:26:24ID:???Singletonやたら多くね？
RequestやらSessionやらControllerやら、
基幹部品ほとんどSingletonになるやん。
0334nobodyさん
2005/06/20(月) 10:13:11ID:???まあ WebProgramming ってのはそういうものな気がする
漏れが1クラスで2つ以上のインスタンスを作るのって composite 系ぐらい
0336332
2005/06/20(月) 17:13:53ID:???あ、そいつは失敬・・・orz
なんか俺が書いた332の文章読み返してみたら、そうとうｲﾊﾟｲﾊﾟｲだな。
反省。
>>333
たしかに制御部分なんかはシングルトンばっかだけどコンテンツと直接関連するとこはけっこうインスタンスつくるな。
インスタンスつくればつくるほど（ＯＯじゃない場合に比べて）重くなっていくのがｳｻﾞｲけど。
ＰＨＰ５だとその辺いかがなもんだろ？
0337333
2005/06/20(月) 19:57:28ID:???Singletonは実装がちょっとだけ面倒だな。
継承で実現できないから毎回同じルーチンをコピペしなきゃならないし。
>>336
4のなんちゃってOOよりは速くなってるはずだよ。
俺もインスタンスのリストも作ってるけど
DBから読んでいっぺんにオブジェクト全部作るより、
一つずつインスタンス作っては表示した方が、メモリ消費量は少ないよなぁとか思いだしたら
一層Singleton傾向が強くなっていくんだよな。
0338nobodyさん
2005/06/20(月) 22:01:02ID:???結構書かれててビビる。
でも便利すぎるから使いまくりな俺。
大丈夫、ResultやらControllerやらConfig何個も作るなんて
ｱﾘｴﾅｲｱﾘｴﾅｲ……
ほとんどデータ格納系となんかの基底クラスだけだ、シングルトン使ってないの。
ヤバいか。ヤバいかも。
0339nobodyさん
2005/06/20(月) 23:34:21ID:???Singletonは便利な反面、保守性を低くしがちでもあるから諸刃の剣だよな。
継承できないのもｲﾀｲ。アクセス制限もｼﾝﾄﾞｲ。
でも便利・・・。
誰かもっとﾋﾞｭｰﾃｨﾎｰなデザパタ考案汁！
とりあえず使いすぎない程度にほどほどでいった方がいいと思うけど。
>>337
基本的には一つずつインスタンス作って表示でいきたいんだけどね〜。
ちょっと特殊なソートをやるときってどうしてもまとめて読み込むしかないんだよな。
ソートが必要だと一般にＤＢにやらせてもどうせ同じだけメモリ食ってるだろうし。
（詳しく知らんけどたぶん）
っていうかＰＨＰにソートをやらせると速度激減ｗ
0340nobodyさん
2005/06/20(月) 23:58:34ID:???その逆も楽。
あっすまん。PHPだと無理だ。
0341nobodyさん
2005/06/21(火) 01:22:49ID:???0342nobodyさん
2005/06/21(火) 03:18:21ID:???0343nobodyさん
2005/06/21(火) 05:18:57ID:m8dmNWb0一つの画面に複数の要素が入ってきて、
要素構成が動的に変化する場合、
viewにどんなオブジェクトを渡すのがいいかな？
たとえば同じRankingオブジェクトでも
メインコンテンツになったりサブコンテンツになったりするので、
Model層でView的な意味あいを考えなくちゃいけないというかさー
ModelにいながらViewしてんじゃんみたいな気持ちになるんだよな
うまいことできねーかな
0344nobodyさん
2005/06/21(火) 06:59:34ID:???Viewは出力しかしないって方向性で。
0346nobodyさん
2005/06/22(水) 16:07:00ID:???0349nobodyさん
2005/06/23(木) 16:32:51ID:???MもVもCもクラス作るんですか？
そして全部シングルトンですか？
教えてくれた人に投げキ○ス。
0350nobodyさん
2005/06/23(木) 16:46:02ID:???基本クラスになるでしょ。
0351nobodyさん
2005/06/23(木) 16:51:40ID:???0352nobodyさん
2005/06/23(木) 17:08:39ID:???だからincludeのみなのは
ちょっとおかしいかも
Modelで意味レベルの情報をViewに渡して
Viewは表示用に整形して、テンプレートに組み込む感じ。
0353nobodyさん
2005/06/23(木) 17:45:35ID:???0354nobodyさん
2005/06/23(木) 18:26:23ID:???>>279です。
VとMはクラス作ってやってます。簡単なものであれば、Cはメインルーチンに突っ込んでます。
メインルーチンはこんな感じ。
$form =& $_POST;
$action = new Action();
$result = $action->execute(&$form);
// 省略するけどここで$resultによってエラー処理などを行う
$view = new View();
$view->execute($form);
フォームの「入力」「確認」「完了」「エラー」のように複数のアクションがあるものは、
MVCを1つずつ作ってメインルーチンからCを呼び出してます。
継承させるとコストが掛かるし呼び出すファイルの枚数考えたらバカバカしいので、
テンプレートのようなコードをMVCの３つ用意しておいてページをつくるたびにコピーして書き足してます。
ただしCを書き直す場面はほとんどないです。
全部シングルトンっちゃシングルトンだけど、本来のシングルトンのように
明示的にインスタンスの複製を禁止するような機構は組み込んでません。
>>353
俺のことかな。
0355nobodyさん
2005/06/23(木) 19:44:02ID:???PHPだしラフに書くことが多いみたいね。
なんかちょっと前まで、このスレ読んでて「みんなシングルトンしっかり書いちゃってるのか？」とか疑問に思ったりした。
まあ結果的にインスタンスを一個ずつしか作ってないってことかな。
そんな漏れはincludeしまくり野郎。
ガンガンファイル数増えるね。
メソッドの中でのincludeはＯＯのありがたみを感じるな。
0356nobodyさん
2005/06/23(木) 20:04:04ID:wsWVtbWS強制するものだということは分かるんだけど、
どんな利点があるのか良く分からないです。
詳しい解説キボンヌなんですが。
0357nobodyさん
2005/06/23(木) 20:23:05ID:???プログラムのどこからでもアクセスできる、ってのが
便利なんだと思う。
俺も>354みたいな感じで処理してるけど、
resultオブジェクトなんかは、そこら中でインスタンス作ってると
Viewで処理するときに混乱しやすいから、Controllerの最初の方で
インスタンス化しておいて、プログラムが走ってる間はそのインスタンスに
アクセスして処理すると。
最終的に全クラスのエラーや処理結果が格納されるから混乱しない。
0358nobodyさん
2005/06/23(木) 20:23:28ID:???> 強制するものだということは分かるんだけど、
それが利点。
たとえばシングルトンにするクラスが他のクラスのインスタンス情報をプログラムの開始から終了まで一括管理してる場合、ヘタにnewされちゃうと管理してた情報が水の泡になってしまうことにもなる。
だからそれを防ぐためにシングルトンにする。
まあ通常はコンストラクタをpublicじゃなくすことで、外部での勝手なnewを禁止するのが常套手段。
だがしかし、PHP厨はただ単純にnewを一回しかやらないことをもって「シングルトン」と呼んでいるらしい。
何か違う気もする。
0359nobodyさん
2005/06/23(木) 22:13:04ID:???HTTPだと、リクエストごとにオブジェクト作り直しなんだから。
0360nobodyさん
2005/06/24(金) 01:05:47ID:???という認識だな
単に一回しかnewしないと自分の中で決めているだけだったら
後から見返した時、呼び出しだけ側だけ見ててもわかりにくいし。
0361nobodyさん
2005/06/24(金) 06:46:55ID:???結局Singletonだけですか？
Composite使いがどこかにいたような。
Listを作る人もいたような気がするのでIteratorも書くのかな？
教えてｴﾛい人！
0362354
2005/06/24(金) 08:05:16ID:???Conpositeパターンは階層構造をサポートしたwiki作る時に使った記憶があるな。
Iteratorは特に意識しなくてもたまたまそういう実装になってしまう時がある。
DBによらない（DBならLIMITで対応できるから）リスト表示でページャをサポートする時など。
そもそも俺はデザインパターン原理主義ではなく、考えた末の実装がたまたまどれかの
デザインパターンに一致することの方が多い。基本的なデザインパターンは一通り
頭に入れてあるが、設計する時にパターンの一覧表とにらめっこしてどれに当てはめるか
考えたりするような真似はしない。
0363nobodyさん
2005/06/24(金) 08:21:41ID:???あんまり見てないけど
ActionChainがなくなったらしいので、その代わりになるようなものなのか
0364nobodyさん
2005/06/24(金) 10:34:44ID:???両方使ったことあったらそれぞれの長所短所を挙げてちょうだいな。
0365nobodyさん
2005/06/24(金) 11:13:34ID:???時代の趨勢は
Mojavi>>>>>Phrameって感じ
Phrame触ってみたことないので中身は知らないけど
0367nobodyさん
2005/06/24(金) 12:32:34ID:???0368nobodyさん
2005/06/24(金) 13:26:31ID:???Mojavi2を一回しか使ったことないけど、その感想。
恐らく勘違いしまくってると思うのでMojaviマスターの方ツッコミ入れてください。
んで便利さを俺に教えてください。
MVCフレームワークとしては良く出来てるが、Webアプリケーションに
ここまでする必要あるのかなあという疑問はある。基本的に全ページ同一の
index.phpから呼ばれる設計になるので、Webの階層構造の利点を捨てて
しまっている。URL_FORMAT=2も冗長。
mojaviのファイル階層が深くて作業しにくい。階層構造になってるのにファイル名長すぎ。
（Action数） * （Actionの戻り値数）個のViewを定義しなきゃならんので、同じような内容のViewが
ずらずら並んでしまう。diff取ったらTemplateファイルを定義してる行だけ違ったとかありがち。
なもんだから、View＋フォームフォーマッタand/orテンプレートエンジンとの連携のところや、
Action(Module)とDaoの連携のところで汚い実装をしちゃうと取り返しのつかないことになる。
ほとんど同じ顔の汚いコードがずらり、みたいな。というか既にそうなっちゃってるところ多し。
「純粋にMVCは提供しただけ。後は好きに使ってくれい」みたいな感じのところがあるので、
プログラマの質によって非MVCスクリプトよりもタチの悪いグチャドロのコードになったり
非常に便利に使えたりの差が大きいと思う。
0369nobodyさん
2005/06/24(金) 14:07:51ID:???たしかにViewだらけになりそうと思った
でもView名は必ず変えなくちゃいけないというわけでもないから
色んな状況を一つのViewクラスで受けてもいいじゃん。
わりと融通がききそうという印象はあるな
0370nobodyさん
2005/06/24(金) 14:59:01ID:???>>368
> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。
DocumentRoot下をちゃんと階層分けしてそれぞれのファイルにアクセスしてもらうように作るのは厳しいかな？
> mojaviのファイル階層が深くて作業しにくい。階層構造になってるのにファイル名長すぎ。
> 同じような内容のViewがずらずら並んでしまう。
禿同。
思ったけどcontrollerの中の〜Exists()をオーバーライドして〜Action.class.phpなどを強制的にやめてファイル名短くするってのはどうかな？
元々付属してきたファイルのケアしなきゃならんのは逆にしんどいだろうか？
まだ始めたばかりなので色々模索中。
0371nobodyさん
2005/06/24(金) 15:00:33ID:???dispatchメソッドの引数にmodule名とaction名を渡せば良いよ
俺はフロントコントローラーとして使ってるけど
おまい様の言うとおりurlが冗長になるので
少しプログラムに手を入れて
index.php/module名/action名
で呼び出せるようにしてる。
mod_rewriteを使うという手もあるね。
2つめは、同意。
仕方ないので我慢してる。
しかし、逆に構成がはっきりしてるので
分かりやすいという利点もあるような気もする。
3つめは、その通りだと思う。
でも、mojavi3-devの次期verで解決するっぽい？
1つのactionにつき1つのviewに対応させるみたいだけど
どうなるのかね。
ttp://forum.mojavi.org/index.php?showtopic=975
0372nobodyさん
2005/06/24(金) 19:58:11ID:???0373nobodyさん
2005/06/25(土) 00:49:00ID:???全部VIEW_SUCCESSを返して(Requestに状況説明ほりこみつつ）
一つのViewクラスで処理するとかすればいいんでないの？
俺が勘違いしてる？
0374nobodyさん
2005/06/25(土) 02:58:54ID:???> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。
どんな利点があんの？
同一から呼ばれてるからこそのフィルタ処理とかのメリットがあるんだが、それ以上のメリットがあるの？
0375nobodyさん
2005/06/25(土) 03:06:12ID:???＞（Action数） * （Actionの戻り値数）個のViewを定義しなきゃならんので、
これ間違いね。
例えば、追加と編集のフォームやバリデーションなんかはViewのロジックはほとんど同じだから、
追加でAction&Viewを作ってやって、編集ではforward&VIEW_NONEでOK
編集用のViewは作らなくてすむ
0377nobodyさん
2005/06/25(土) 03:23:44ID:???＞同一のファイルから呼ばれなくても同じクラス再利用すればいいのでは？
いってることが違うんだけど、どう言えば理解できるかなぁ…
0378376
2005/06/25(土) 03:27:27ID:???> 同一から呼ばれてるからこそのフィルタ処理とかのメリットがある
の部分だけにつっこんでみた。
>>368への反論としての意味は考慮してなかった。
0380nobodyさん
2005/06/25(土) 03:31:04ID:???index.phひとつpで経由してるから、個別の処理をクラスとして定義できて、forwardやactionchainみたいな
処理が可能になってるわけだけど、バラバラにしちゃった場合どうすんの？
あ、あとmod_rewriteでいじくる場合もこっちのが楽っぽいよね
0381nobodyさん
2005/06/25(土) 03:33:03ID:???↑まちがえた
0382nobodyさん
2005/06/25(土) 03:35:40ID:???dispatchの引数色々変えられるし。
ファイルわけとけば継承した自作Controller呼べる選択の余地もあるし。
とか言って実際やってみたわけではないがｗ
0384nobodyさん
2005/06/25(土) 03:39:29ID:???0385nobodyさん
2005/06/25(土) 03:46:31ID:???これはあんまりメリットにならんよね。
Controllerが違う時点でMVCから外れちゃってるし
てかactionChain理解してる？
0386nobodyさん
2005/06/25(土) 04:12:24ID:???Strutsの場合はサーブレットを基点に考えられてるから、そうせざるを得ないかもしれないけど。
ユーザやデザイナ、更新作業するオペレータって、ディレクトリ構造になれてるからね。戸惑うことが多いだろうね。
SEO的にも問題があるし。
0387nobodyさん
2005/06/25(土) 04:16:35ID:???MojaviとかSmartyはむしろもっと機能を減らした方がバランスがいいんじゃないかな。
0388nobodyさん
2005/06/25(土) 04:39:46ID:???たぶん話がくいちがってるな。
まず俺は「ファイル分け推奨派」側ではないので。べつにindex.phpで問題なし。
ただファイル分けしたいとかいう意見も面白いと思った。
同じサーバ上で複数の異なるサービス展開したいとか、URLレベルではModule/Actionの組み合わせ以外でアクセスされたいとか個々人で事情があるんだろうし。
まーMojaviの標準から外れた方法使う分手間はかかるだろうが、大したことないでしょ。
で、その上で俺の言いたかったのは、再利用するなら同じクラス（または継承クラス）使えばいいだけでしょ、という話。
フィルタだろうがアクションだろうが。
別にファイル階層化の方が利点があるかどうかには俺は言及してない。
0389nobodyさん
2005/06/25(土) 06:56:49ID:???まーね。
とは言っても小規模ならフレームワーク使わなくてもいいわけだし、MojaviやSmartyはPHPの可能性を広げてるって見方もあると思うけど。
「不必要な機能は使わなければいい」ってのは当たり前に思えることにもかかわらず、実際にはそれが明確になりにくいから「無駄に多機能」って印象も生まれるんではないかと。
高機能・多機能にすればするほど重くなるのは確かだが、MojaviやSmartyで「無駄に重くなってる」って感じはしないかも。
0390nobodyさん
2005/06/25(土) 14:50:03ID:???俺はアクセスカウンタでも自作フレームワーク使ってるけどね。
MojaviもStrutsもそれ自体の機脳をおぼえなくてはいけないので
冗長すぎると俺は思う。
0391nobodyさん
2005/06/25(土) 14:59:09ID:???片っ端から全部覚えようとするから冗長に思えるのでは？
0392nobodyさん
2005/06/25(土) 15:32:24ID:???> Webの階層構造の利点
これについては、URIにおいて階層構造でドキュメントの位置を特定できるという
本来のWebの意義を捨てるのはどうなのかなあという事です。
階層ごとにアクセス制限をつけるといったこともやりにくいですよね。
>>371の方法はスマートですね。なければ作れよと。自分がプログラマなのを忘れてました。
>>373
それだと何のためにActionがリザルトコード返してるんだよ？って問題になりそうなので。
エラー処理をVIEW_SUCCESSに処理させるのって見通し的に問題ありません？
>>391
冗長すぎるというよりも、Webの世界ではmojaviが当てはまるほどの規模の開発があまりないって事ですかね。
いまだに「会員登録」「一覧表示」「ドキュメント管理」「買い物システム」みたいな案件が多いですから。
先般mojaviで頼まれた案件は、自作のフレームワークの方が工数1/4くらいで済みそうでした。
昔作った計1000ページ近くに及ぶ顧客・企業・オーナーを結ぶデータベースへのアクセスインターフェイス、
あのくらいの規模だとmojaviでやったら工数減ったかも。
0393nobodyさん
2005/06/26(日) 05:32:44ID:???まずパッケージの中身見たらSmartyViewが空っぽでした。
とりあえずPHPViewをほぼ真似てSmartyViewを自作。
しかし、Smartyのキャッシュ機能のせいで、ActionとかFilterとか編集したときにそれが反映されない。
仕方ないので編集中はSmartyのキャッシュを無効に切り替えて対応。
なんか今後も振り回されそうな悪寒もあり。
よりよい方法はありませんか？
0394nobodyさん
2005/06/26(日) 12:03:06ID:???とりあえず「もはび」と語尾上がりで読んでしまう。
桶？
0396nobodyさん
2005/06/26(日) 13:08:30ID:???0397nobodyさん
2005/06/26(日) 13:10:59ID:???0398nobodyさん
2005/06/26(日) 13:12:33ID:???0399nobodyさん
2005/06/26(日) 13:36:13ID:???0400nobodyさん
2005/06/26(日) 13:40:55ID:???0401nobodyさん
2005/06/26(日) 13:47:17ID:???0402nobodyさん
2005/06/26(日) 14:08:20ID:???0403nobodyさん
2005/06/26(日) 14:11:37ID:???0404nobodyさん
2005/06/26(日) 14:28:16ID:???0405nobodyさん
2005/06/26(日) 14:28:58ID:???|´∀｀';/^l
|u'''^u;' |
|∀ ｀ ﾐ ﾀﾞﾚﾓｲﾅｲ･･･
| ⊂ :, ﾓｼﾞｬﾓｼﾞｬ ｽﾙﾅﾗ ｲﾏﾉｳﾁ
| ﾐ
| 彡
| ,:'
|''~''''∪
l^丶
ﾓｼﾞｬﾓｼﾞｬ | 'ﾞ''"'''ﾞ y-―,
ﾐ ´ ∀ ｀ ,:'
(丶 (丶 ミ
（（ ﾐ ;': ﾊ,_,ﾊ
;: ﾐ ';´∀｀';,
`:; ,:' ｃ ｃ.ﾐ
U"ﾞ'''~"＾'丶) u''ﾞ"J
/^l
,―-y'"'~"ﾞ´ | ﾓｼﾞｬﾓｼﾞｬ
ヽ ´ ∀ ｀ ﾞ':
ﾐ .,/) ､/)
ﾞ, "' ´''ﾐ ﾊ,_,ﾊ
（（ ミ ;:' ,:' ´∀｀';
'; 彡 :: っ ,っ
(/~"ﾞ''´~"U ι''"ﾞ''u
0406nobodyさん
2005/06/26(日) 16:24:17ID:???0407nobodyさん
2005/06/26(日) 16:27:02ID:???もうねぇ、語源とかどーでもいいよ。
俺たち日本人はアルファベットを見るとローマ字読みしたくなる人種なんだよ。
モジャビ、モジャビ。
モジャビで決定。
>>405
わかったわかった。
0408nobodyさん
2005/06/26(日) 17:24:40ID:???日本人は律儀な方だと思うよ。アメリカ人なんてグルジア共和国
とかヨハネ・パウロ二世とか全部英語読みだもんな。
「mojavi pronounce」でググったらこんなん見つけた。
やっぱり奴らはモジャヴィで抵抗ないらしい。
http://forum.mojavi.org/index.php?showtopic=1077
つーかググった結果が33件って。mojaviでググっても
日本語のページばかりだし、日本でしか流行ってないのか。
0409nobodyさん
2005/06/26(日) 18:14:35ID:???そこの書き込み読ませてもらったけど、モハーベ砂漠（アメリカにある砂漠）に倣ってｈで発音する派もいるみたいじゃん。
ちなみにモハーベ砂漠のMojaveの発音は「モゥ・ハァ・ヴィ」って感じのようだ。
ハァのとこにストレスで。
http://www.answers.com/mohave
↑発音も聞けるｗ
あと、「33件かよーっ！？」って思って俺もググってみたら実際はもうちょい出たよ
http://www.google.com/search?hl=en&q=mojavi
Results 1 - 10 of about 45,200 for mojavi. (0.04 seconds)
とりあえず俺はモハービでいくとするかな。
0410nobodyさん
2005/06/26(日) 20:06:06ID:???> あと、「33件かよーっ！？」って思って俺もググってみたら実際はもうちょい出たよ
いや、33件しか出なかったのは 「mojavi pronounce」でググった結果について。
mojavi単体で45,200ってのもかなり少ないね。
日本語googleの結果が1万件くらいだから1/4弱が日本語のページってことになる。
0411nobodyさん
2005/06/26(日) 20:45:24ID:???日本人の情報収集力の高さと見るか。
単に新しいもの好きですぐとびつきたくなるタチと見るか。
0412nobodyさん
2005/06/26(日) 21:36:48ID:???ちょっとしたフレームワークを作ろうと思って、
Factoryに引数を与えるとその名前でクラスを生成してくる、
みたいなのを考えてるんですが。
■ このスレッドは過去ログ倉庫に格納されています