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

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

1:nobodyさん
08/08/24 21:43:37
前スレ
ｽﾚﾘﾝｸ(php板)

2:nobodyさん
08/08/24 21:44:41
※ このスレは【PHP】フレームワークについて語るスレ11【総合】です

いきなりミス。ｽﾏｿ...

3:nobodyさん
08/08/24 21:47:34
過去スレ
【PHP】フレームワークについて語るスレ10【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ9【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ8【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ7【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ6【総合】
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ5[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ4[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ３[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ２[総合]
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ【総合】
ｽﾚﾘﾝｸ(php板)

4:nobodyさん
08/08/24 21:48:23
【洋モノ】
symfony
URLﾘﾝｸ(www.symfony-project.com)
code igniter
URLﾘﾝｸ(codeigniter.com)
Zend Framework
URLﾘﾝｸ(framework.zend.com)
CakePHP
URLﾘﾝｸ(www.cakephp.org)

【和モノ】
ちいたん
URLﾘﾝｸ(php.cheetan.net)
Ethna
URLﾘﾝｸ(ethna.jp)
guesswork
URLﾘﾝｸ(classic.guesswork.jp)
maple
URLﾘﾝｸ(kunit.jp)

5:nobodyさん
08/08/24 22:11:57
Mapleイラネ

6:nobodyさん
08/08/25 14:32:05 qgfF3K9X
agavi
age

7:nobodyさん
08/08/25 16:50:03
何使おうか考え中
ZendがPHPにかなり力を入れてるから将来性があると思うんだけど
評価が悪くて使えそうにない

8:nobodyさん
08/08/25 16:54:50
>>7
ちいたん使えｗｗｗ
で「今回のプロジェクトではフレームワークとして「ちいたん」を採用しました」
って上司に報告してくれｗｗｗ

9:nobodyさん
08/08/25 16:58:15 hwjRu6i6
セッションデータって毎回全体を読み書きするから
あんまり大きいデータは扱いたくないよな。
かといってテンポラリーなデータを永続データが入ってるDBに突っ込むのは
抵抗がある。
こういう場合どうする？

10:nobodyさん
08/08/25 17:14:13
>>9
XMLファイルにでもしておけば？

11:nobodyさん
08/08/25 17:25:37
xmlって一部を読み書きできるの？
結局全読み・全書きになるのでは？

12:nobodyさん
08/08/25 18:59:26
>>9
1. 気にせずDBに放り込む
2. 「永続データが入って」いないDBに放り込む
3. 「一部を読み書きできる」ように細分化してファイルに放り込む
4. 気にせず毎回全部読み書きする

なんでもいいんじゃないの？

13:nobodyさん
08/08/25 20:03:51
>>7
zend使ってくれ
専用スレが過疎ってつまんないから

14:nobodyさん
08/08/25 21:13:10
>>7
>評価が悪くて使えそうにない
せめて情報が無くて使えそうにないって言ってくれｗ

ユーザの声（マニュアルではない、もすこし身近なTips、ノウハウなど）が
圧倒的に不足しているよね

でもそれはどのフレームワークも一緒か。
そもそも乱立しすぎじゃね？
例えばせめてライブラリ系はZendを使うとか、そんな風潮になればノウハウは
蓄積されていくんだろうけど

15:nobodyさん
08/08/25 23:48:18
シンプルなページを各フレームワークで実装したベンチマーク
URLﾘﾝｸ(talks.php.net)

結果だけまとめると
1位素のPHP
　 611.78 trans/s
2位 CodeIgniter 1.6.3
　 305.9　trans/s
3位 Solar 1.0.0alpha1
　 271.18 trans/s
4位 Zend Framework 1.6.0-rc1
　 130.08 trans/s
5位 Agavi 1.0-beta1
　 126.91 trans/s
6位 Symfony 1.1
　 100.63 trans/s
7位 Prado 3.1.2
　　76.95 trans/s
8位 Drupal 6.4
　　51.37 trans/s
9位 CakePHP 1.2.0rc2
　　25.88 trans/s

16:nobodyさん
08/08/26 00:48:34 lM6BRZm9
>>9
マジレスすると、セッションみたいな永続じゃないデータの場合memcache使うのが良い。
レンサバじゃ無理だけどな。

17:nobodyさん
08/08/26 01:23:19
cakephpってそんな遅いんだ。

18:nobodyさん
08/08/26 01:38:25
>>15
DrupalってF.W.じゃないじゃんｗ。

それより遅いcakeって・・・・。

19:nobodyさん
08/08/26 10:05:38
いちおうDrupalはCMS向けのモジュラー式フレームワークってことになってる。

20:nobodyさん
08/08/26 11:02:15
cakeで開発しようと思ったけど、
cakeもどきの俺様フレームワーク作ってやるかな。

21:nobodyさん
08/08/26 23:18:20
そういや、PEAR2ってどうなったの？

22:nobodyさん
08/08/27 00:05:44
PEAR2は5.3合わせでしょ

23:nobodyさん
08/08/27 11:52:55 n0GZd29C
思ったんですが、
singletonって全部staticなクラスとほとんど同じでは？
むしろ、singletonの機構を書く必要がない分、
staticなクラスの方がいいのではないかとも思うのですが
singletonのアドバンテージって何ですか？

24:nobodyさん
08/08/27 12:52:05
>>23
顔洗って出直して来い

25:nobodyさん
08/08/27 15:02:44
signletonはobject
(PHPの)クラスはobjectではない

ぜんぜん違うだろ

26:nobodyさん
08/08/27 15:06:09
顔洗って出直してきました。

で？

27:nobodyさん
08/08/27 15:13:19
全然違うって言う奴は分かってないだけ
分かってる人の返答お待ちしております

28:nobodyさん
08/08/27 15:56:42
唯一のインスタンスを取り扱うためのsingletonでしょ
なのにstaticなクラスがいいとか全然違うよ
分かってないのはあなた
singletonをもう一度調べ直してみ

29:nobodyさん
08/08/27 16:01:55
メソッドはstaticでもつかえるし、PHP5からはデータもクラスで持てる

Hoge::page() ではなく Hoge::instance()->page() にするメリットはなにかと
言うことだと思うんだけど

まあインスタンスにしておけば、変数に放り込んで引数で渡したり、
簡単に別クラスに差し替えたり、そう言う事ができるかもしれない
私もよくわからんので、違うっていう人の親切な解説があれば嬉しいな

30:nobodyさん
08/08/27 17:22:46
singletonはsingletonっていうインスタンスは必ず一つなのが
保証されますよっていうパターンの概念なわけで、別に
staticなクラスの作りでsingleton的な扱いをすることもできるだろうけど、
ただそれが「singletonって全部staticなクラスとほとんど同じ」かと
言われればそりゃ違うって答えるだろう
概念の話とコードレベルの話だし質問がおかしい

ある程度有名なパターンだからsingletonってこういうもの、
という共通認識がプログラマにあるのがアドバンテージなわけであって
このクラスはsingletonだからインスタンスは唯一、とすぐ把握できるところを
オレオレsingleton概念で「これ俺なりのsingleton！インスタンスはナイっス！」
とか言われても困るわけで

Hoge::page() と Hoge::instance()->page() 云々も一緒で
要はそのクラスがどういう扱いなのかというのを認識するのに
singletonというパターンがあるよってだけの話であって
singletonだから絶対Hoge::instance()->page()な形ってわけでもないし
コードレベルの問題とはまた別の話かと

31:nobodyさん
08/08/27 17:55:26
>>23の無知さに全米が泣いたｗ

32:nobodyさん
08/08/27 17:56:52
>>23はバカなの？死ぬの？

33:nobodyさん
08/08/27 18:06:57
PHPでコンピュータプログラミングを学ぼうとすると、こうなっちゃう
ってことですね

34:nobodyさん
08/08/27 18:12:39 8yHWP9d0
23 nobodyさん [] Date:2008/08/27(水) 11:52:55 　ID:n0GZd29C Be:
　　思ったんですが、
　　 singletonって全部staticなクラスとほとんど同じでは？
　　むしろ、singletonの機構を書く必要がない分、
　　 staticなクラスの方がいいのではないかとも思うのですが
　　 singletonのアドバンテージって何ですか？

晒しage

35:nobodyさん
08/08/27 18:27:10
おまえら説明出来ないからってシンプルに叩きすぎだｗ

36:nobodyさん
08/08/27 19:08:36
ウェブアプリだとシングルトンパターンなんて使い道があんまりないからな。せいぜいDBハンドラぐらいだけど、それも普通にグローバル変数で扱えば十分だし。

37:nobodyさん
08/08/28 02:21:17
結局説明はできない、と。
得意げにsingletonの解説始めちゃう奴なんなの？
そういうのを東洋じゃ釈迦に説法って言うんだぜ。

38:nobodyさん
08/08/28 03:28:58
どこに釈迦がいるってんだい。
おつむがおしゃかな奴なら確かにいるようだが。

39:nobodyさん
08/08/28 08:08:13
C++だとグローバル変数では初期化のタイミング不確定だから、シングルトンは有用だったりするけどな

40:nobodyさん
08/08/28 14:16:10
>>23は質問自体が痛ｲよね

41:nobodyさん
08/08/28 21:36:39
答えられなかった奴が必死の自己肯定ｗｗ
反論するなら論理的にしろ。な？

42:nobodyさん
08/08/28 21:49:55
>>23の質問は別に痛いと思わない
痛々しさではむしろ>>31-34の方が

んで、>>23はsingletonと同じではないけど、別にそれでも
いいんじゃない？っていう認識はどんなもんですか＞エロい人

唯一性（？）の保証なら、コンストラクタ隠し忘れてたり__clone()上書き
してなかったりする半端singletonよりは確実とか考えたり。（そんな奴いない？）
インスタンスとして扱う必要がなくて、「singleton」と言いさえしなければ、
あれも十分実用的な考え方だと思うけど

叩くなら叩け

43:nobodyさん
08/08/28 22:07:43
object としてのふるまいが必要でないならそれでいいんじゃねえの。

44:nobodyさん
08/08/28 22:08:43
staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
>>30で十分説明してあるし、それ読んで分からないようなら、素養がなさ過ぎるので、プログラミングなんか止めた方が良い。
河原で野球でもしてろ。

45:nobodyさん
08/08/28 22:26:50
>>30で書いているのは、singletonはパターンの名前で、型であり概念であると
いうことでおｋ？

OO言語でのstatic等と言うものの理解が全然ないのは確かだから
申し訳ないが、singletonと、くだんの実装方法との最大の違いはインスタンスを
使うかどうか、っていうことだけと思ってしまう。それはsingletonの概念に含まれるの？

>>23の手法に、また別な名前があったなら話はシンプルだとかそういう話？

46:nobodyさん
08/08/28 22:33:07
そこで意表をついてガンパレードマーチ配信ですよ

47:nobodyさん
08/08/28 22:35:06
誤爆ｽﾏｿ

48:nobodyさん
08/08/28 22:49:37
>>45
もともとsingletonってデザインパターンは、Javaでのデザインパターンの話だし、
JavaプログラミングだとThreadって概念も出てくるから、全部staticなクラスよりも
singletonのほうが都合が良いとか、そういうことなんじゃないの？

49:nobodyさん
08/08/28 23:05:35
>>48
うん。もともと、そういう実際上の都合も絡めての話題だと思った
てか singleton static でちょっとググっただけでわんさか出てきた

URLﾘﾝｸ(java-house.jp)
URLﾘﾝｸ(www.aerith.net)
URLﾘﾝｸ(www.atmarkit.co.jp)
URLﾘﾝｸ(www.sk-jp.com)
URLﾘﾝｸ(oldblog.xenophy.com)
URLﾘﾝｸ(tome-programming.cocolog-nifty.com)

↑（結構アレなのも混ざってるけど）
意外とみんな引っかかる点なんじゃないの？
>>23がそこで悩んだとしたら、むしろセンスがあるんじゃね？

痛いっていってる人らはみんなきっとこれを乗り越えているんだろうが優しくねえなー

50:nobodyさん
08/08/28 23:25:03
>>49
俺も>>23の質問に対する正しい解答は知りたい。

>>44がいってる
＞staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
っていうのも、少しずれてて、

>>23は、
全部staticなクラスを作るというデザインパターン　と　singletonというデザインパターンを比較してるのであって。

で、>>30の回答も、
そのアプリケーションを扱う人間が全部staticなクラスを作るというデザインパターンに対して共通認識を持ててたとしたら、
特に不都合は無い、ってことなのかな。

51:nobodyさん
08/08/29 01:26:14
全部staticなクラスって単なる構造化プログラミングじゃん。

52:nobodyさん
08/08/29 01:39:13
>>51
それは言えるかも。オブジェクト指向ではないと。
まあぶっちゃけstaticなプロパティを、globalsのいらないglobal変数として
使ってる私が通りますよ、と。
原則がないといくら文法がJavaに近くなっても意味がないってことはありそう

でもそれはデザインパターンと直接には関係しないような
singletonにしたって、普通にglobalじゃんっていう評価みたいだし。俺はよくわからんけどね

53:23
08/08/29 03:15:53
オブジェクト指向は単なる表記方法ではなく考え方なので、
全部staticのクラスだろうがオブジェクト指向にすることは可能。
さらにいえば、別にクラスがなくても可能。
スレッドのないPHPではsingletonに色んなざっくばらんな代替方法があると。
ただ汎用的な知識としてはJavaのやり方が無難で
わざわざ他の方法をとることもないということだな。
よくわかった。

54:nobodyさん
08/08/29 03:25:48
えらく短絡的なまとめきたー
てかそんな投げやりなまとめなら23とか名乗らず名無しで書けよｗ

ちょっとでも擁護したレスが軒並み後悔するような、嫌な感じだｗｗｗ
さあ寝よ

55:nobodyさん
08/08/29 03:31:33
？
別に君に擁護されなくても全く困らんよ？
もともと馬鹿に的外れな批判されても痛くもなんともないし

56:nobodyさん
08/08/29 09:09:19 EVgfNfnd
>>30みたいな説明じゃ、シングルトンがなにかも、staticメソッドと比べての利点もわかんないよ。
こんな説明をする先輩いるけど、ほんと自己満足だよな。

シングルトンのかわりにstaticメソッドでもいいじゃんというのは、そのとおり。
$obj = FooClass::getInstance();
$obj->method();
とするだけなら
FooClass::method();
でいいじゃんと思うのは自然なこと。

ただシングルトンはオブジェクト指向の機能を使えるので、
・継承が使える
・他のメソッドに引数として渡したりできる(オブジェクトなので)
・任意個の個数に設定できる(１個である必要はない)
という利点がある。こういった点が必要ないなら、staticメソッドで構わないよ。
たとえば
$obj = FooClass::getInstance();
other_function($obj);
ということをしたかったら、staticメソッドじゃなくてシングルトンのほうが自然だよね。

シングルトンもstaticメソッドもあくまで手段でしかないので、目的がstaticメソッドで満たせるなら
staticメソッドでもいいんじゃない。

57:nobodyさん
08/08/29 10:42:02
rubyのmixinみたいなことしたいのですが、どうしたらいいですか？
クラス定義の中から、
class Hoge {
self::mixin('OtherClass');
}
↓
HogeにOtherClassがmixinされる
みたいな形にしたいのですが。
runkitは不安定だったので使いたくありません。

58:nobodyさん
08/08/29 10:51:30
__call でがんばるか、ruby を使ってください

59:nobodyさん
08/08/29 11:13:07 YM8BIoOF
>>57
RhacoというフレームワークではMix-inをサポートしているそうだからみてみるといいかも。
URLﾘﾝｸ(rhaco.org)

URLﾘﾝｸ(ll.jus.or.jp)
> 変態的国産PHPフレームワークrhaco
> doctest、distutils、mix-in等PHPでは聞き慣れない機能について紹介します。

60:nobodyさん
08/08/29 11:39:37
>>59
ありが㌧みてみます
とりあえずsymfonyのsfMixerを見てみたけど
__callの中からsfMixerを呼んで、そこでバックトレース情報を利用して
混ぜられた側のメソッドにデレゲートしてる感じ
この方法だと、混ぜられた側のメソッドから
混ぜてる側のメンバにアクセスできないような・・・

61:nobodyさん
08/08/29 12:35:23
rhacoのmixinはeval使ってました
速度さえ気にしなければeval使えば大抵のことできますね～
evalでいくしかないかな

62:nobodyさん
08/08/29 13:15:34
全部staticメソッドにするというなら、それは構造化プログラミングそのものなわけで、それと比較するなら、オブジェクト指向プログラミングだろ。
シングルトンパターンという実装パターンの一つとじゃ比較の対象にならない。

63:nobodyさん
08/08/29 13:57:50
構造化プログラミングとOOPを峻別してる奴なんなの？
OOPは構造化プログラミングを含んでるんだよ
書き方の問題ではない

64:nobodyさん
08/08/29 19:54:55 YM8BIoOF
>>62
なに難しいこといってんの？
シングルトンでやろうとしていることは、staticメソッドでもできるんじゃね？というだけの話。
なんで構造化プログラムだとかオブジェクト指向との比較とかでてくるの？ばかなの？

65:nobodyさん
08/08/30 03:25:30
>>57
runkitは使ったことないですが、これは使ってます。
URLﾘﾝｸ(d.hatena.ne.jp)
qiqもすごくいい。もう普通のPHPは書けなくなるｗ
URLﾘﾝｸ(d.hatena.ne.jp)

66:nobodyさん
08/08/30 04:23:53
構造化プログラミングとオブジェクト指向プログラミングは比較して語られるものだよ。
あるプログラム、ある言語をを見て、それが構造化プログラミングなものなのか、オブジェクト指向プログラミングなのか、区別されるんだから。
その区別が出来ないというのは、人類皆兄弟とかいうたぐいの屁理屈だ。

67:nobodyさん
08/08/30 11:36:30
もうお馬鹿ちゃんは書かない方がいいんじゃないか
自分を大きく見せようとする努力ほど無意味なものはない

68:nobodyさん
08/08/30 12:39:53
オブジェクト指向プログラミングは、構造化プログラミングを含んでいるものだから、
プログラムを見て、オブジェクト指向プログラミング特有のクラス等を
（正しく）使っていればオブジェクト指向、使っていなければ構造化って判断をするな。

69:nobodyさん
08/08/30 18:14:35 OmTt4XZu
RUBYはオブジェクト指向を前提とした言語で、PERLは本来構造化言語なのをパッケージをクラスに流用することでオブジェクト指向の機能を持たせている。
昔の8ビットマイコン時代のBASICはGOTO文で処理を行き来する非構造化言語。
このプログラミングのパラダイムシフトは世界の共通認識だから。

70:nobodyさん
08/08/30 20:22:14
>>68
「～判断をするな。」が、I do なのか you shouldn't do なのかわからん
>>69
>このプログラミングのパラダイムシフトは世界の共通認識だから。
だから、何なんだ

どうせならもう少し結論を明確にしてもいいんじゃないかと思う
話がふわふわして仕方がないｗ

71:nobodyさん
08/08/30 20:38:57 /jeGwvoC
はじめまして、質問させてください。
社内でWebサービス構築のために
MVCモデルのPHPフレームワークを作ることになったのですが、
どのあたりまでの実装でフレームワークとして体をなすのか分かりません。
どなたか教えていただけませんでしょうか？

72:nobodyさん
08/08/30 20:57:57
それが分からない人達がフレームワークを作ることに意味があるとは思えない
既存のものを使った方がいいのでは？

73:nobodyさん
08/08/30 21:07:18 /jeGwvoC
回答ありがとうございます。
私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？

74:nobodyさん
08/08/30 21:12:11
>>72
オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）

>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど

だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？

極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う

75:nobodyさん
08/08/30 21:29:08 /jeGwvoC
>>74
>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。

実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。

76:nobodyさん
08/08/30 21:46:18
MVCにこだわるなら
　・各データの出し入れの基礎的な記述と、各データごとのロジック
　・表示に関する基礎的な記述とロジック
を、実行スクリプトから切り離すのが最低限？
例えば、昔よく見た

<?php
// DB接続処理ほげほげ
　（省略）
　$sql = 'SELECT * FROM customer;';
$ret = mysql_query($sql, $db);
$rows = array();
while($row = mysql_fetch_assoc($ret)){ $rows[] = $row; }
?>
<html>
（略）
<?php
　foreach($rows as $row){
　　（略）
}
?>
（略）
</html>

なんてのを、どう分けるか、何のために分けるか、というお話だと思うんだ。
その具体的な分け方・方向については・・・うーん俺は人に教えるほど
きちんと勉強していません。頑張れ！（ｵｲ）

77:nobodyさん
08/08/30 22:03:54 /jeGwvoC
>>76
ありがとうございます。参考にさせていただきます。

78:nobodyさん
08/08/31 11:40:02
>>75
えーとな。
まずフレームワークを使ってから
考えれ。

79:nobodyさん
08/08/31 18:59:51
>>75
>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？

CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。

後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。

>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。

で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)

80:nobodyさん
08/08/31 22:02:43 BcOgvLp9
ありがとうございます。
ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。

それにしても結構種類ありますよね～。

81:nobodyさん
08/08/31 22:18:42
>>80
とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。

後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。

82:nobodyさん
08/08/31 23:09:43
骨は例えばちいたんでもいいのでは
他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし

ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い

83:nobodyさん
08/08/31 23:44:28 BcOgvLp9
>>81
なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。

>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。

ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。

84:nobodyさん
08/09/01 07:50:32
しかし、PEARやADODBを使えるのにフレームワークは自作しなきゃならん意味が分からんな。

85:nobodyさん
08/09/01 16:27:37
勝ち馬に乗れなくてサポートが止まったらどうするんだ、とか、
複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。

自作FWなんて最初からサポート止まってるも同然なんだけど。

あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？

86:nobodyさん
08/09/01 20:42:35
フレームワーク使うと大幅に工数下がるね。
でも、フレームワークを勉強するためのコストが要るね。

でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。

87:nobodyさん
08/09/02 15:46:31
自分の印象では、CodeIgniterは分かりやすくて良かったです。
SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。

「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？

88:nobodyさん
08/09/02 19:21:26 kKY94AaP
一般的に、フレームワークでは、
データベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？

89:nobodyさん
08/09/02 20:08:08
>>88
参照整合性制約（外部キー）までチェックしてデータ操作してくれる
モデルを実装しているフレームワークは寡聞にして聞いたことが無い。
有ったら俺も知りたいな。

90:nobodyさん
08/09/02 20:41:21
Zend_Dbはそんな感じのやつあったんじゃね？

91:nobodyさん
08/09/02 20:51:11
ON DELETE CASCADEではだめなん?
DBのパフォーマンスのため、参照整合性制約を付けずにアプリケーション側で
実装する場合もあるとは思うけど、外部キー制約してるんだよね?

92:nobodyさん
08/09/09 00:13:17
既出だけどsabelなるフレームワークが出てるけど、最近はルーティングとかYAMLとかの設定ファイルに書かないのが流行りなの？

93:nobodyさん
08/09/13 19:22:25 lKt9XZcp
テンプレートメソッドってだいたいprotectedにするじゃん
そしてzend規約では、protectedなメソッドの名前は_hogeにする
でも、子に_付きのメソッドのオーバーライドを求めるのって
何かきもくね？
_を付けるってのは、「内側で使ってる」っていうしるしで、
テンプレートメソッドは、子とはいえ、自分以外に実装をまかせるという、
ある種の外側志向。その齟齬がきもさの原因と思う。
publicにするか、規約を破るか、きもさを受け入れるか・・悩ましいぜ

94:nobodyさん
08/09/13 21:34:17
そういう文化的な気持ち悪さはわかりにくいな
例えば private と protected をわけるスタイルもある
_ と __ とか（←わかりにくいｗ）

Zendは特にわけてないのかな？

95:nobodyさん
08/09/13 22:06:52
__は__setとか__constratみたいのがあるじゃん

96:nobodyさん
08/09/13 22:09:06
↑予約メソッドをリストアップして回避すればいいじゃん
そんなに無いよ

97:nobodyさん
08/09/13 22:11:08
そこはPHPが糞としか言いようがないな
せめて予約メソッドは、__set__ とか __clone__ とかにしておいてくれればｗ

98:nobodyさん
08/09/13 22:12:10
めんどい

99:nobodyさん
08/09/13 22:14:01
___set っていうのもありか。

コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは

__reserved_method_CONSTRUCT()

くらいやってくれてもなんの問題もないしな

100:nobodyさん
08/09/13 22:25:24
->が一番嫌いなんだよな
.がいいよな.のほうがカッコいい

101:nobodyさん
08/09/13 22:30:28
>>96
__ で始まるのは全部予約メソッドなんだが

102:nobodyさん
08/09/13 22:35:44
>>100
そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・

Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ

>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。

103:nobodyさん
08/09/13 22:53:57
protectedとprivateは別物なのに、_で一緒くたにしているのは、
ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？

104:nobodyさん
08/09/13 22:59:30
>>103
publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない

> protectedとprivateは別物なのに、

っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ

105:nobodyさん
08/09/14 00:28:45
>>100
.のが使いやすいのは同意なんだけど、加算演算子と文字列連結演算子が別なのは
PHPの数少ない美点の一つだと思ってる。

106:nobodyさん
08/09/14 01:05:36
>>105
それは単純にPerl由来なんだけどな。$ と同様に。
$ の使い方としては劣化してるし、この辺はもうPerl文化を切り捨てるか、
PHPの独自路線が欲しい所ではある

107:nobodyさん
08/09/14 01:09:29
配列が@とか%じゃないのは良いよな
あれきもいし

108:nobodyさん
08/09/14 02:35:06
PHPってびっくりするほど独自路線というものが無い言語のような気が...
Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。

あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw

109:nobodyさん
08/09/14 03:31:07
ユニコードモードって何が変わるの？

110:nobodyさん
08/09/14 04:04:33
未だにPHP４とかの鯖あるし
４，５，６とか大変なんだが～

111:nobodyさん
08/09/14 04:10:29
新規案件で4の鯖はないっしょ。てか誘導しようよ
保守案件で4なら、ご苦労様としか言えぬｗ

6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ

112:nobodyさん
08/09/14 09:51:48
別にPHP4でも困らないけどな。PHP5の機能で役に立つのは例外くらいなもんだし。

113:nobodyさん
08/09/14 10:42:39
オブジェクトが代入でコピーされなくなったのは、地味に気持ちいい

114:nobodyさん
08/09/14 10:44:44
&付ければいいだけじゃん。

115:nobodyさん
08/09/14 11:30:26
cloneだろ

116:nobodyさん
08/09/14 14:34:14
4だから困るとか言うよりは、2系統あるのが困る

117:nobodyさん
08/09/16 20:53:37
>>115
コピーって言っちゃだめなの？

118:nobodyさん
08/09/16 23:08:17
>>117
>115は>114に対して

119:nobodyさん
08/09/17 13:33:07
PHPをやめるとしたら、何を使いますか？
・Ruby
・Python
・Perl

やっぱPythonかな？

120:nobodyさん
08/09/17 13:35:32
Perlは個人的にないな。

121:nobodyさん
08/09/17 13:41:27
>>119
仕事的には、PHPより高速で安定的に動作して、
月額1000円程度以上のレンサバには95%以上の確率で入ってるなら
なんでもいい。

そんなのある？

122:nobodyさん
08/09/17 13:43:47
つPerl & FastCGI
FastCGIの方は、95%にはちと足りんかな？ｗ

123:nobodyさん
08/09/17 13:50:56
Rubyに移行しようと思ったけど
ZendStudioがあるから結局PHP使ってる・・

124:nobodyさん
08/09/17 18:12:51
書いてて面白いのはPerlだね。

125:nobodyさん
08/09/17 18:45:58
じょうだんよしこさん

126:nobodyさん
08/09/17 22:00:15
PHPのつまらなさは異常

127:nobodyさん
08/09/18 02:36:03
qiq入れればまだ楽しめるよ

128:nobodyさん
08/09/18 16:41:27
ますかきおくん

129:nobodyさん
08/09/18 16:49:43
qiq面白いとは思うけど
コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると

130:nobodyさん
08/09/18 16:52:54
楽しめても、業務利用は無理っしょ
まだRubyで楽しんでる方が健全じゃねーかｗｗｗ

131:nobodyさん
08/09/18 19:11:26
趣味用の言語ならもっとマイナーな奴でもやれよ

132:nobodyさん
08/09/18 19:12:59 ykJuPDO5
>>129
別に、フレームワーク使ったってそのフレームワークに依存するじゃん
なんでQIQだと抵抗があるのか

133:nobodyさん
08/09/18 20:57:09
そりゃあんた、なんか不可解な挙動があったときに、どこまで自分の力で
調べて修正できるのかって点で、違いすぎるだろｗ

ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが

134:nobodyさん
08/09/18 21:38:02
将来PHPがバージョンアップして
qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。

135:nobodyさん
08/09/19 00:57:48
PHPにもApacheにも何も保証があるわけじゃないのに。
PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？　そりゃ失礼しました。

136:nobodyさん
08/09/19 03:33:16
>>135
確率の問題

137:nobodyさん
08/09/19 12:02:16
PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい

>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？

ひょっとして全部同列に見えるくらいのスーパーハカーですか？

138:nobodyさん
08/09/19 18:10:39
PHPユーザーは裾野が広いってことでしょう。
サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方

139:nobodyさん
08/09/20 13:23:29
ラムダとか5.3で導入されるじゃん
qiqって何が素晴らしいの？

140:nobodyさん
08/09/20 13:42:12
前スレでさんざん出てた [] じゃね？
執着してる人が結構いるようだし

141:nobodyさん
08/09/21 05:27:57
[]とハッシュ{}はほしいねぇ
あと -> を . にすれば書くのも読むのも楽だ

142:nobodyさん
08/09/21 05:32:43
C/C++の話かよｗ

143:nobodyさん
08/09/21 18:00:01
>>137
>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか

おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。

PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。

144:nobodyさん
08/09/21 19:43:02
> QIQなんてただのライブラリにすぎないんだから、
ライ・・ブラリ・・・？

> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ

145:nobodyさん
08/09/21 20:08:55
QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。

146:nobodyさん
08/09/21 21:37:07
あれはPHPの拡張モジュール作るのには必要ない、文書化もされていないようなAPIを叩いてるからね...
単体では短くても、理解しようとするとZend Engineのソースコード全体を見る羽目になるw

それとは関係ないけど、拡張モジュールを作るなら何気にPHP6はAPIが使いやすくなってる。
5.3もUnicode関連を除いてほぼ6相当だけど、便利な関数が5.3だけZEND_APIとしてエクスポートされていなくて切ないことも。

147:nobodyさん
08/09/22 00:20:44
>>145
>QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
それはおまえがWebのスキルしかないから。コンパイラコンパイラの初歩知識があれば、見れば分かる。
自分が慣れてる分野のコードは読めて、知識のない分野のコードは読めないのは当然。

148:nobodyさん
08/09/22 00:46:48
PHPで描かれたウェブのフレームワークとPHPのエクステンション、どっちが難解かは子供でも分かること

149:nobodyさん
08/09/22 01:04:16
いや、量によって変わるから、どちらが難解かは一概に言えない。

ただいえるのは、PHPという言語仕様を非公式変えてしまうようなものは
公式でPHPそのものが変わったときに対応が困難になるから
使うのはやめておけってこった。

150:nobodyさん
08/09/22 07:15:01
公式でPHPが変わったら、どっちもどっちじゃない?

151:nobodyさん
08/09/22 10:49:18
じゃない。

152:nobodyさん
08/09/22 16:45:08
アホな質問かも知れないけど、cakephpライクなフレームワークを作ろうかと
思ってるんですが、マジックメソッドの __get使ってモデルやコンポーネントの
呼び出しを下のようにやってみたいんだけど、何か問題あります？

class HogeController extends Controller
{
　　function index()
　　{
　　　$data = $this->Model->classname->find();
　　　$this->Component->classname->hogehoge();
　　}
}

153:nobodyさん
08/09/23 00:47:41
>>152
$this->Modelとか$this->Componentの__get()で、
与えられたクラス名のオブジェクトを生成・取得するって仕組み？
特に悪いとも思わないけど、必要とか便利とかもあんまり思わないｗ

例えば設計思想とか、利用時の利便性とかもあるんだろうけど、
同じ事をするのに、Model::factory()とかModel::singleton()でも
いい場合もあるかもだし

ピントはずれだったらｽﾏｿ

154:nobodyさん
08/09/23 00:51:04
>>153 微妙に修正
> 同じ事をするのに、Model::factory()とかModel::singleton()でも
→ 同じ事をするのに、Model::factory(classname) とか new classname() とか classname::singleton() とかでも

155:nobodyさん
08/09/23 02:07:19
new は method chain できないから却下

156:152
08/09/23 15:14:04
cakephpだとコントローラーのプロパティに
使うコンポーネント設定するのいちいち面倒だな～と思ってたんで。
そういうやり方もあるんですね、勉強になります。有り難うございました。

157:nobodyさん
08/09/23 17:34:13
∧＿∧
（　´∀｀）＜ぬるぽプロジェクト

みんなで面白いサイト作って有名にしようぜ！
ｽﾚﾘﾝｸ(news4vip板)
★まとめwiki
URLﾘﾝｸ(www39.atwiki.jp)

PHPのフレームワークとして symfonyを採用予定です。

158:nobodyさん
08/09/23 20:55:42
>>157
スレ荒れすぎワロタ

159:nobodyさん
08/09/23 21:24:50
>>158
自動保守おいしいです（^q^）

160:nobodyさん
08/09/26 16:21:57
フレームワークとは直接関係ないけど5.3でspl_autoload_register(function($name){...});
すると実際にautoloadされるときにbus erorrで落ちるね。
spl_autoload_register($f=function($name){...}); なら$fが生きている間だけは落ちない。

161:nobodyさん
08/09/26 16:42:24
5が出ても枯れるまで結構時間かかったし
6も使えるようになるまでは長いだろうなぁ

162:nobodyさん
08/09/27 08:37:12
一人で最初期モックアップ作るなら、
railsとcakephpと、どっちが向いてる？

163:nobodyさん
08/09/28 11:02:03
その比較って意味あるのかな？
Ruby（少なくともRails）とPHPが同等にできる人にとってしか答えようがないし、
回答もしかりw

164:nobodyさん
08/09/28 11:49:26
cakeみたいな厨フレームワーク使ってる人恥ずかしくないんですかぁ

165:nobodyさん
08/09/28 15:59:10
んじゃ何使えばいいの？

166:nobodyさん
08/09/28 18:15:32
☆Z☆E☆N☆D☆!!

167:nobodyさん
08/09/28 22:06:23
Zend…

無いわー

168:nobodyさん
08/09/28 23:15:36
zend使いまくりだけど
何が不満なのかわからない

169:nobodyさん
08/09/29 06:03:55
モックならちいたんで良いジャマイカ。

170:nobodyさん
08/09/30 00:08:37
モックなら素のPHPでいいよ

171:nobodyさん
08/09/30 00:17:33
モックはHTMLで十分なこともおおくない？ｗ
ヘッダフッタ辺りのレイアウトとかで楽したいなら、
手慣れたテンプレートエンジンがあればいいかもだけど

フレームワークってのとはちょっと違うような
多分必要なのはView側の省力化・柔軟性かなあ

172:nobodyさん
08/09/30 00:41:51
マックでいいよ

173:nobodyさん
08/09/30 01:56:27
楽天がセッションidごとgoogleにキャッシュされ、
個人情報を漏らしまくって最終的にPHP脂肪ｗｗｗ

174:nobodyさん
08/09/30 03:55:27 CLW/UbJj
物区ならPencilでいいんじゃね

175:nobodyさん
08/09/30 06:24:36
つーかsymfony一択だろ
フレームワーク作者で一番センスあるコード書くのがフランチョス。

176:nobodyさん
08/09/30 07:01:23
symfonyは関数名がダサい
_区切りとかKENTかよｗ

177:nobodyさん
08/09/30 07:07:59
そんな規約ないよ
何かと間違えてないか？

178:nobodyさん
08/09/30 07:12:10
あれれ～symfonyじゃなかったっけ？

179:nobodyさん
08/09/30 07:26:27
symfonyはJavaと同じキャメルケースだよ

180:nobodyさん
08/09/30 19:28:17
そもそもPHPの標準関数の命名がいい加減なんだから、拘っても意味ない。

181:nobodyさん
08/10/01 01:38:54
PHPはキャメルケースとアンダースコア混在しまくってるからな
クラス名とか関数名とか考えるとき、どっちにしようかいつも迷ってしまう

182:nobodyさん
08/10/01 01:50:42
それ単に昔の関数と最近のクラスメソッドなだけだろ

183:nobodyさん
08/10/01 07:31:56
将来的にはほとんどオブジェクト指向のラッパーが用意されて
関数は地下に潜った存在になるだろうな

184:nobodyさん
08/10/02 19:06:50
最近のは殆どキャメルケースに一本化の流れなんかね
アンダースコア派だったからどうもなじめない

185:nobodyさん
08/10/02 19:46:59
オブジェクト指向な関数（メソッド）で
アンダースコアが普及しているような言語あるの？

186:nobodyさん
08/10/02 19:54:09
るｂｙ

187:nobodyさん
08/10/02 19:55:23
くそ言語wｗ

188:nobodyさん
08/10/02 19:59:51
PHPに言われたらしめぇだべ

189:nobodyさん
08/10/02 20:29:01
PHPよりも糞な言語なんてINTERCALくらいだろ

190:nobodyさん
08/10/02 20:58:24
キャメルケースでも、メソッド名でM$流のUpperCamelCaseは勘弁して欲しい
それはクラス名だけでいいと思う

191:nobodyさん
08/10/02 21:19:41
メソッドをアッパーキャメルケースで書く人なんているの？
そんなコード見たことない

192:nobodyさん
08/10/02 21:28:23
C#とかかじった人はやる。
携帯ミドルウェアとかやっててC/C++は触るがJavaは触らない、って人もやる。
まあぶっちゃけ Java vs. C# なんだけど、PHPは中途半端なので混在してる。

その点Rubyは、作ってる・使ってる人間がC・Perl on *nix の人メインなので、
アンダースコア派が主流なのかな
また、RubyではUpperCamelCaseは文法的に定数扱いされるので、メソッド名や
通常の変数名には使えない。・・・MS流が嫌いなのか？ｗ

193:nobodyさん
08/10/03 00:28:34
そういう書き方の自由を奪う言語は嫌われる。

194:nobodyさん
08/10/03 02:07:48
Rubyの_でつなぐのはPerl由来だろうね。俺は_でつなぐのが見やすくて好きだけどな。
PHPはJava風なんだけど、初期に出来た関数の命名が超適当だからな。引数の取り方とかも。
C#とかJavaはどうせIDE使うんで、まあ、どうでもいいような気がする。

195:nobodyさん
08/10/03 11:11:04
大文字小文字を区別しないものにCamelCaseを使うのは、ちょっと気持ち悪い

196:nobodyさん
08/10/03 14:57:50
キャメルケースの種類

アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)
　　複合語の先頭を、大文字で書き始める。
　　つづり例：CamelCase

ローワーキャメルケース (LCC)、または単にキャメルケース
　　複合語の先頭を、小文字で書き始める。
　　つづり例：camelCase

197:nobodyさん
08/10/03 15:09:46
なんでわざわざ書いたん？
自分用メモか？

198:nobodyさん
08/10/03 15:43:33
初めて知ってうれしかった

199:nobodyさん
08/10/03 16:36:40
CSSですらできる多重継承ができないPHPって一体・・・

200:nobodyさん
08/10/03 17:18:11
Mixinがあれば多重継承なんて必要ありませんよ

201:nobodyさん
08/10/03 17:57:27
>>199
Javaもですが・・

202:nobodyさん
08/10/03 18:04:06
Mixinを提供しているRubyだけがCSSと肩を並べているということですね

203:nobodyさん
08/10/03 19:59:32
つまり、いや、やめておこう

204:nobodyさん
08/10/03 20:27:36
>>185
pythonもメソッド名は、アンダースコアが一般的かな。
クラス名はキャメルケースだけど。

205:nobodyさん
08/10/03 20:55:12
最後の文字だけ大文字にする逆キャメルケースにしてる人いる？
geThogEとか

206:nobodyさん
08/10/03 23:42:27
>>205
どうでもいいけど、読みづらくね？

207:nobodyさん
08/10/03 23:48:08
ゲソォグイーと読んでしまった

208:nobodyさん
08/10/04 00:29:16
>>205
まずそうしようと思った意図はなんだｗ
さすがにこれは利点も考え付かんｗｗ

209:nobodyさん
08/10/04 00:31:58
難読化とかｗ

210:nobodyさん
08/10/04 04:52:10
<?php
class Class_Name
{
　　 public function methodName( )
　　 {
　　　　　functionName($valOne, $valTwo);
　　　　　if ($a == 1){
　　　　　　 $b = 2;
　　　　　}
　　 }

命名規則、俺の結論はこのあたり。
URLﾘﾝｸ(framework.zend.com)
URLﾘﾝｸ(solarphp.org)
Zend, Solarあたり守っとけばPEARの規約でも問題ない。あとクラス名は_で区切っとかないとauto loaderがめんどい。

次ページ