- 1 名前：nobodyさん mailto:sage [2008/08/24(日) 21:43:37 ID:???]
- 前スレ
pc11.2ch.net/test/read.cgi/php/1202521438/
- 44 名前：nobodyさん mailto:sage [2008/08/28(木) 22:08:43 ID:???]
- staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
>>30で十分説明してあるし、それ読んで分からないようなら、素養がなさ過ぎるので、プログラミングなんか止めた方が良い。
河原で野球でもしてろ。
- 45 名前：nobodyさん mailto:sage [2008/08/28(木) 22:26:50 ID:???]
- >>30で書いているのは、singletonはパターンの名前で、型であり概念であると
いうことでおｋ？
OO言語でのstatic等と言うものの理解が全然ないのは確かだから
申し訳ないが、singletonと、くだんの実装方法との最大の違いはインスタンスを
使うかどうか、っていうことだけと思ってしまう。それはsingletonの概念に含まれるの？
>>23の手法に、また別な名前があったなら話はシンプルだとかそういう話？
- 46 名前：nobodyさん mailto:sage [2008/08/28(木) 22:33:07 ID:???]
- そこで意表をついてガンパレードマーチ配信ですよ
- 47 名前：nobodyさん mailto:sage [2008/08/28(木) 22:35:06 ID:???]
- 誤爆ｽﾏｿ
- 48 名前：nobodyさん mailto:sage [2008/08/28(木) 22:49:37 ID:???]
- >>45
もともとsingletonってデザインパターンは、Javaでのデザインパターンの話だし、
JavaプログラミングだとThreadって概念も出てくるから、全部staticなクラスよりも
singletonのほうが都合が良いとか、そういうことなんじゃないの？
- 49 名前：nobodyさん mailto:sage [2008/08/28(木) 23:05:35 ID:???]
- >>48
うん。もともと、そういう実際上の都合も絡めての話題だと思った
てか singleton static でちょっとググっただけでわんさか出てきた
ttp://java-house.jp/ml/archive/j-h-b/048394.html
ttp://www.aerith.net/design/Singleton-j.html#no_use_case
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=22377&forum=12&start=16&23
ttp://www.sk-jp.com/java/pattern/singleton.html
ttp://oldblog.xenophy.com/index.php?entry=entry061224-024857
ttp://tome-programming.cocolog-nifty.com/blog/2006/08/singletonstatic_365e.html
↑（結構アレなのも混ざってるけど）
意外とみんな引っかかる点なんじゃないの？
>>23がそこで悩んだとしたら、むしろセンスがあるんじゃね？
痛いっていってる人らはみんなきっとこれを乗り越えているんだろうが優しくねえなー
- 50 名前：nobodyさん mailto:sage [2008/08/28(木) 23:25:03 ID:???]
- >>49
俺も>>23の質問に対する正しい解答は知りたい。
>>44がいってる
＞staticメソッドとシングルトンパターンとじゃ、比較したり置き換えたり出来るもんじゃないんだよ。
っていうのも、少しずれてて、
>>23は、
全部staticなクラスを作るというデザインパターン と singletonというデザインパターンを比較してるのであって。
で、>>30の回答も、
そのアプリケーションを扱う人間が全部staticなクラスを作るというデザインパターンに対して共通認識を持ててたとしたら、
特に不都合は無い、ってことなのかな。
- 51 名前：nobodyさん mailto:sage [2008/08/29(金) 01:26:14 ID:???]
- 全部staticなクラスって単なる構造化プログラミングじゃん。
- 52 名前：nobodyさん mailto:sage [2008/08/29(金) 01:39:13 ID:???]
- >>51
それは言えるかも。オブジェクト指向ではないと。
まあぶっちゃけstaticなプロパティを、globalsのいらないglobal変数として
使ってる私が通りますよ、と。
原則がないといくら文法がJavaに近くなっても意味がないってことはありそう
でもそれはデザインパターンと直接には関係しないような
singletonにしたって、普通にglobalじゃんっていう評価みたいだし。俺はよくわからんけどね
- 53 名前：23 mailto:sage [2008/08/29(金) 03:15:53 ID:???]
- オブジェクト指向は単なる表記方法ではなく考え方なので、
全部staticのクラスだろうがオブジェクト指向にすることは可能。
さらにいえば、別にクラスがなくても可能。
スレッドのないPHPではsingletonに色んなざっくばらんな代替方法があると。
ただ汎用的な知識としてはJavaのやり方が無難で
わざわざ他の方法をとることもないということだな。
よくわかった。
- 54 名前：nobodyさん mailto:sage [2008/08/29(金) 03:25:48 ID:???]
- えらく短絡的なまとめきたー
てかそんな投げやりなまとめなら23とか名乗らず名無しで書けよｗ
ちょっとでも擁護したレスが軒並み後悔するような、嫌な感じだｗｗｗ
さあ寝よ
- 55 名前：nobodyさん mailto:sage [2008/08/29(金) 03:31:33 ID:???]
- ？
別に君に擁護されなくても全く困らんよ？
もともと馬鹿に的外れな批判されても痛くもなんともないし
- 56 名前：nobodyさん [2008/08/29(金) 09:09:19 ID:EVgfNfnd]
- >>30みたいな説明じゃ、シングルトンがなにかも、staticメソッドと比べての利点もわかんないよ。
こんな説明をする先輩いるけど、ほんと自己満足だよな。
シングルトンのかわりにstaticメソッドでもいいじゃんというのは、そのとおり。
$obj = FooClass::getInstance();
$obj->method();
とするだけなら
FooClass::method();
でいいじゃんと思うのは自然なこと。
ただシングルトンはオブジェクト指向の機能を使えるので、
・継承が使える
・他のメソッドに引数として渡したりできる(オブジェクトなので)
・任意個の個数に設定できる(１個である必要はない)
という利点がある。こういった点が必要ないなら、staticメソッドで構わないよ。
たとえば
$obj = FooClass::getInstance();
other_function($obj);
ということをしたかったら、staticメソッドじゃなくてシングルトンのほうが自然だよね。
シングルトンもstaticメソッドもあくまで手段でしかないので、目的がstaticメソッドで満たせるなら
staticメソッドでもいいんじゃない。
- 57 名前：nobodyさん mailto:sage [2008/08/29(金) 10:42:02 ID:???]
- rubyのmixinみたいなことしたいのですが、どうしたらいいですか？
クラス定義の中から、
class Hoge {
self::mixin('OtherClass');
}
↓
HogeにOtherClassがmixinされる
みたいな形にしたいのですが。
runkitは不安定だったので使いたくありません。
- 58 名前：nobodyさん mailto:sage [2008/08/29(金) 10:51:30 ID:???]
- __call でがんばるか、ruby を使ってください
- 59 名前：nobodyさん [2008/08/29(金) 11:13:07 ID:YM8BIoOF]
- >>57
RhacoというフレームワークではMix-inをサポートしているそうだからみてみるといいかも。
rhaco.org/
ll.jus.or.jp/2007/show/Event/Session/
> 変態的国産PHPフレームワークrhaco
> doctest、distutils、mix-in等PHPでは聞き慣れない機能について紹介します。
- 60 名前：nobodyさん mailto:sage [2008/08/29(金) 11:39:37 ID:???]
- >>59
ありが㌧みてみます
とりあえずsymfonyのsfMixerを見てみたけど
__callの中からsfMixerを呼んで、そこでバックトレース情報を利用して
混ぜられた側のメソッドにデレゲートしてる感じ
この方法だと、混ぜられた側のメソッドから
混ぜてる側のメンバにアクセスできないような・・・
- 61 名前：nobodyさん mailto:sage [2008/08/29(金) 12:35:23 ID:???]
- rhacoのmixinはeval使ってました
速度さえ気にしなければeval使えば大抵のことできますね～
evalでいくしかないかな
- 62 名前：nobodyさん mailto:sage [2008/08/29(金) 13:15:34 ID:???]
- 全部staticメソッドにするというなら、それは構造化プログラミングそのものなわけで、それと比較するなら、オブジェクト指向プログラミングだろ。
シングルトンパターンという実装パターンの一つとじゃ比較の対象にならない。
- 63 名前：nobodyさん mailto:sage [2008/08/29(金) 13:57:50 ID:???]
- 構造化プログラミングとOOPを峻別してる奴なんなの？
OOPは構造化プログラミングを含んでるんだよ
書き方の問題ではない
- 64 名前：nobodyさん [2008/08/29(金) 19:54:55 ID:YM8BIoOF]
- >>62
なに難しいこといってんの？
シングルトンでやろうとしていることは、staticメソッドでもできるんじゃね？というだけの話。
なんで構造化プログラムだとかオブジェクト指向との比較とかでてくるの？ばかなの？
- 65 名前：nobodyさん mailto:sage [2008/08/30(土) 03:25:30 ID:???]
- >>57
runkitは使ったことないですが、これは使ってます。
d.hatena.ne.jp/rsky/20080124/1201186473
qiqもすごくいい。もう普通のPHPは書けなくなるｗ
d.hatena.ne.jp/rsky/20080301/1204326365
- 66 名前：nobodyさん mailto:sage [2008/08/30(土) 04:23:53 ID:???]
- 構造化プログラミングとオブジェクト指向プログラミングは比較して語られるものだよ。
あるプログラム、ある言語をを見て、それが構造化プログラミングなものなのか、オブジェクト指向プログラミングなのか、区別されるんだから。
その区別が出来ないというのは、人類皆兄弟とかいうたぐいの屁理屈だ。
- 67 名前：nobodyさん mailto:sage [2008/08/30(土) 11:36:30 ID:???]
- もうお馬鹿ちゃんは書かない方がいいんじゃないか
自分を大きく見せようとする努力ほど無意味なものはない
- 68 名前：nobodyさん mailto:sage [2008/08/30(土) 12:39:53 ID:???]
- オブジェクト指向プログラミングは、構造化プログラミングを含んでいるものだから、
プログラムを見て、オブジェクト指向プログラミング特有のクラス等を
（正しく）使っていればオブジェクト指向、使っていなければ構造化って判断をするな。
- 69 名前：nobodyさん [2008/08/30(土) 18:14:35 ID:OmTt4XZu]
- RUBYはオブジェクト指向を前提とした言語で、PERLは本来構造化言語なのをパッケージをクラスに流用することでオブジェクト指向の機能を持たせている。
昔の8ビットマイコン時代のBASICはGOTO文で処理を行き来する非構造化言語。
このプログラミングのパラダイムシフトは世界の共通認識だから。
- 70 名前：nobodyさん mailto:sage [2008/08/30(土) 20:22:14 ID:???]
- >>68
「～判断をするな。」が、I do なのか you shouldn't do なのかわからん
>>69
>このプログラミングのパラダイムシフトは世界の共通認識だから。
だから、何なんだ
どうせならもう少し結論を明確にしてもいいんじゃないかと思う
話がふわふわして仕方がないｗ
- 71 名前：nobodyさん [2008/08/30(土) 20:38:57 ID:/jeGwvoC]
- はじめまして、質問させてください。
社内でWebサービス構築のために
MVCモデルのPHPフレームワークを作ることになったのですが、
どのあたりまでの実装でフレームワークとして体をなすのか分かりません。
どなたか教えていただけませんでしょうか？
- 72 名前：nobodyさん mailto:sage [2008/08/30(土) 20:57:57 ID:???]
- それが分からない人達がフレームワークを作ることに意味があるとは思えない
既存のものを使った方がいいのでは？
- 73 名前：nobodyさん [2008/08/30(土) 21:07:18 ID:/jeGwvoC]
- 回答ありがとうございます。
私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？
- 74 名前：nobodyさん mailto:sage [2008/08/30(土) 21:12:11 ID:???]
- >>72
オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）
>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど
だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？
極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う
- 75 名前：nobodyさん [2008/08/30(土) 21:29:08 ID:/jeGwvoC]
- >>74
>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。
実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。
- 76 名前：nobodyさん mailto:sage [2008/08/30(土) 21:46:18 ID:???]
- 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さん [2008/08/30(土) 22:03:54 ID:/jeGwvoC]
- >>76
ありがとうございます。参考にさせていただきます。
- 78 名前：nobodyさん mailto:sage [2008/08/31(日) 11:40:02 ID:???]
- >>75
えーとな。
まずフレームワークを使ってから
考えれ。
- 79 名前：nobodyさん mailto:sage [2008/08/31(日) 18:59:51 ID:???]
- >>75
>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？
CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。
後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。
>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。
で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)
- 80 名前：nobodyさん [2008/08/31(日) 22:02:43 ID:BcOgvLp9]
- ありがとうございます。
ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。
それにしても結構種類ありますよね～。
- 81 名前：nobodyさん mailto:sage [2008/08/31(日) 22:18:42 ID:???]
- >>80
とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。
後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。
- 82 名前：nobodyさん mailto:sage [2008/08/31(日) 23:09:43 ID:???]
- 骨は例えばちいたんでもいいのでは
他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし
ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い
- 83 名前：nobodyさん [2008/08/31(日) 23:44:28 ID:BcOgvLp9]
- >>81
なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。
>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。
ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。
- 84 名前：nobodyさん mailto:sage [2008/09/01(月) 07:50:32 ID:???]
- しかし、PEARやADODBを使えるのにフレームワークは自作しなきゃならん意味が分からんな。
- 85 名前：nobodyさん mailto:sage [2008/09/01(月) 16:27:37 ID:???]
- 勝ち馬に乗れなくてサポートが止まったらどうするんだ、とか、
複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。
自作FWなんて最初からサポート止まってるも同然なんだけど。
あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？
- 86 名前：nobodyさん mailto:sage [2008/09/01(月) 20:42:35 ID:???]
- フレームワーク使うと大幅に工数下がるね。
でも、フレームワークを勉強するためのコストが要るね。
でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。
- 87 名前：nobodyさん mailto:sage [2008/09/02(火) 15:46:31 ID:???]
- 自分の印象では、CodeIgniterは分かりやすくて良かったです。
SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。
「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？
- 88 名前：nobodyさん [2008/09/02(火) 19:21:26 ID:kKY94AaP]
- 一般的に、フレームワークでは、
データベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？
- 89 名前：nobodyさん mailto:sage [2008/09/02(火) 20:08:08 ID:???]
- >>88
参照整合性制約（外部キー）までチェックしてデータ操作してくれる
モデルを実装しているフレームワークは寡聞にして聞いたことが無い。
有ったら俺も知りたいな。
- 90 名前：nobodyさん mailto:sage [2008/09/02(火) 20:41:21 ID:???]
- Zend_Dbはそんな感じのやつあったんじゃね？
- 91 名前：nobodyさん mailto:sage [2008/09/02(火) 20:51:11 ID:???]
- ON DELETE CASCADEではだめなん?
DBのパフォーマンスのため、参照整合性制約を付けずにアプリケーション側で
実装する場合もあるとは思うけど、外部キー制約してるんだよね?
- 92 名前：nobodyさん mailto:sage [2008/09/09(火) 00:13:17 ID:???]
- 既出だけどsabelなるフレームワークが出てるけど、最近はルーティングとかYAMLとかの設定ファイルに書かないのが流行りなの？
- 93 名前：nobodyさん [2008/09/13(土) 19:22:25 ID:lKt9XZcp]
- テンプレートメソッドってだいたいprotectedにするじゃん
そしてzend規約では、protectedなメソッドの名前は_hogeにする
でも、子に_付きのメソッドのオーバーライドを求めるのって
何かきもくね？
_を付けるってのは、「内側で使ってる」っていうしるしで、
テンプレートメソッドは、子とはいえ、自分以外に実装をまかせるという、
ある種の外側志向。その齟齬がきもさの原因と思う。
publicにするか、規約を破るか、きもさを受け入れるか・・悩ましいぜ
- 94 名前：nobodyさん mailto:sage [2008/09/13(土) 21:34:17 ID:???]
- そういう文化的な気持ち悪さはわかりにくいな
例えば private と protected をわけるスタイルもある
_ と __ とか （←わかりにくいｗ）
Zendは特にわけてないのかな？
- 95 名前：nobodyさん mailto:sage [2008/09/13(土) 22:06:52 ID:???]
- __は__setとか__constratみたいのがあるじゃん
- 96 名前：nobodyさん mailto:sage [2008/09/13(土) 22:09:06 ID:???]
- ↑予約メソッドをリストアップして回避すればいいじゃん
そんなに無いよ
- 97 名前：nobodyさん mailto:sage [2008/09/13(土) 22:11:08 ID:???]
- そこはPHPが糞としか言いようがないな
せめて予約メソッドは、__set__ とか __clone__ とかにしておいてくれればｗ
- 98 名前：nobodyさん mailto:sage [2008/09/13(土) 22:12:10 ID:???]
- めんどい
- 99 名前：nobodyさん mailto:sage [2008/09/13(土) 22:14:01 ID:???]
- ___set っていうのもありか。
コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは
__reserved_method_CONSTRUCT()
くらいやってくれてもなんの問題もないしな
- 100 名前：nobodyさん mailto:sage [2008/09/13(土) 22:25:24 ID:???]
- ->が一番嫌いなんだよな
.がいいよな.のほうがカッコいい
- 101 名前：nobodyさん mailto:sage [2008/09/13(土) 22:30:28 ID:???]
- >>96
__ で始まるのは 全部 予約メソッドなんだが
- 102 名前：nobodyさん mailto:sage [2008/09/13(土) 22:35:44 ID:???]
- >>100
そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・
Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ
>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。
- 103 名前：nobodyさん mailto:sage [2008/09/13(土) 22:53:57 ID:???]
- protectedとprivateは別物なのに、_で一緒くたにしているのは、
ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？
- 104 名前：nobodyさん mailto:sage [2008/09/13(土) 22:59:30 ID:???]
- >>103
publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない
> protectedとprivateは別物なのに、
っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ
- 105 名前：nobodyさん mailto:sage [2008/09/14(日) 00:28:45 ID:???]
- >>100
.のが使いやすいのは同意なんだけど、加算演算子と文字列連結演算子が別なのは
PHPの数少ない美点の一つだと思ってる。
- 106 名前：nobodyさん mailto:sage [2008/09/14(日) 01:05:36 ID:???]
- >>105
それは単純にPerl由来なんだけどな。$ と同様に。
$ の使い方としては劣化してるし、この辺はもうPerl文化を切り捨てるか、
PHPの独自路線が欲しい所ではある
- 107 名前：nobodyさん mailto:sage [2008/09/14(日) 01:09:29 ID:???]
- 配列が@とか%じゃないのは良いよな
あれきもいし
- 108 名前：nobodyさん mailto:sage [2008/09/14(日) 02:35:06 ID:???]
- PHPってびっくりするほど独自路線というものが無い言語のような気が...
Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。
あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw
- 109 名前：nobodyさん mailto:sage [2008/09/14(日) 03:31:07 ID:???]
- ユニコードモードって何が変わるの？
- 110 名前：nobodyさん mailto:sage [2008/09/14(日) 04:04:33 ID:???]
- 未だにPHP４とかの鯖あるし
４，５，６とか大変なんだが～
- 111 名前：nobodyさん mailto:sage [2008/09/14(日) 04:10:29 ID:???]
- 新規案件で4の鯖はないっしょ。てか誘導しようよ
保守案件で4なら、ご苦労様としか言えぬｗ
6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ
- 112 名前：nobodyさん mailto:sage [2008/09/14(日) 09:51:48 ID:???]
- 別にPHP4でも困らないけどな。PHP5の機能で役に立つのは例外くらいなもんだし。
- 113 名前：nobodyさん mailto:sage [2008/09/14(日) 10:42:39 ID:???]
- オブジェクトが代入でコピーされなくなったのは、地味に気持ちいい
- 114 名前：nobodyさん mailto:sage [2008/09/14(日) 10:44:44 ID:???]
- &付ければいいだけじゃん。
- 115 名前：nobodyさん mailto:sage [2008/09/14(日) 11:30:26 ID:???]
- cloneだろ
- 116 名前：nobodyさん mailto:sage [2008/09/14(日) 14:34:14 ID:???]
- 4だから困るとか言うよりは、2系統あるのが困る
- 117 名前：nobodyさん mailto:sage [2008/09/16(火) 20:53:37 ID:???]
- >>115
コピーって言っちゃだめなの？
- 118 名前：nobodyさん mailto:sage [2008/09/16(火) 23:08:17 ID:???]
- >>117
>115は>114に対して
- 119 名前：nobodyさん mailto:sage [2008/09/17(水) 13:33:07 ID:???]
- PHPをやめるとしたら、何を使いますか？
・Ruby
・Python
・Perl
やっぱPythonかな？
- 120 名前：nobodyさん mailto:sage [2008/09/17(水) 13:35:32 ID:???]
- Perlは個人的にないな。
- 121 名前：nobodyさん mailto:sage [2008/09/17(水) 13:41:27 ID:???]
- >>119
仕事的には、PHPより高速で安定的に動作して、
月額1000円程度以上のレンサバには95%以上の確率で入ってるなら
なんでもいい。
そんなのある？
- 122 名前：nobodyさん mailto:sage [2008/09/17(水) 13:43:47 ID:???]
- つPerl & FastCGI
FastCGIの方は、95%にはちと足りんかな？ｗ
- 123 名前：nobodyさん mailto:sage [2008/09/17(水) 13:50:56 ID:???]
- Rubyに移行しようと思ったけど
ZendStudioがあるから結局PHP使ってる・・
- 124 名前：nobodyさん mailto:sage [2008/09/17(水) 18:12:51 ID:???]
- 書いてて面白いのはPerlだね。
- 125 名前：nobodyさん mailto:sage [2008/09/17(水) 18:45:58 ID:???]
- じょうだんよしこさん
- 126 名前：nobodyさん mailto:sage [2008/09/17(水) 22:00:15 ID:???]
- PHPのつまらなさは異常
- 127 名前：nobodyさん mailto:sage [2008/09/18(木) 02:36:03 ID:???]
- qiq入れればまだ楽しめるよ
- 128 名前：nobodyさん mailto:sage [2008/09/18(木) 16:41:27 ID:???]
- ますかきおくん
- 129 名前：nobodyさん mailto:sage [2008/09/18(木) 16:49:43 ID:???]
- qiq面白いとは思うけど
コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると
- 130 名前：nobodyさん mailto:sage [2008/09/18(木) 16:52:54 ID:???]
- 楽しめても、業務利用は無理っしょ
まだRubyで楽しんでる方が健全じゃねーかｗｗｗ
- 131 名前：nobodyさん mailto:sage [2008/09/18(木) 19:11:26 ID:???]
- 趣味用の言語ならもっとマイナーな奴でもやれよ
- 132 名前：nobodyさん [2008/09/18(木) 19:12:59 ID:ykJuPDO5]
- >>129
別に、フレームワーク使ったってそのフレームワークに依存するじゃん
なんでQIQだと抵抗があるのか
- 133 名前：nobodyさん mailto:sage [2008/09/18(木) 20:57:09 ID:???]
- そりゃあんた、なんか不可解な挙動があったときに、どこまで自分の力で
調べて修正できるのかって点で、違いすぎるだろｗ
ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが
- 134 名前：nobodyさん mailto:sage [2008/09/18(木) 21:38:02 ID:???]
- 将来PHPがバージョンアップして
qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。
- 135 名前：nobodyさん mailto:sage [2008/09/19(金) 00:57:48 ID:???]
- PHPにもApacheにも何も保証があるわけじゃないのに。
PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？ そりゃ失礼しました。
- 136 名前：nobodyさん mailto:sage [2008/09/19(金) 03:33:16 ID:???]
- >>135
確率の問題
- 137 名前：nobodyさん mailto:sage [2008/09/19(金) 12:02:16 ID:???]
- PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい
>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？
ひょっとして全部同列に見えるくらいのスーパーハカーですか？
- 138 名前：nobodyさん mailto:sage [2008/09/19(金) 18:10:39 ID:???]
- PHPユーザーは裾野が広いってことでしょう。
サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方
- 139 名前：nobodyさん mailto:sage [2008/09/20(土) 13:23:29 ID:???]
- ラムダとか5.3で導入されるじゃん
qiqって何が素晴らしいの？
- 140 名前：nobodyさん mailto:sage [2008/09/20(土) 13:42:12 ID:???]
- 前スレでさんざん出てた [] じゃね？
執着してる人が結構いるようだし
- 141 名前：nobodyさん mailto:sage [2008/09/21(日) 05:27:57 ID:???]
- []とハッシュ{}はほしいねぇ
あと -> を . にすれば書くのも読むのも楽だ
- 142 名前：nobodyさん mailto:sage [2008/09/21(日) 05:32:43 ID:???]
- C/C++の話かよｗ
- 143 名前：nobodyさん mailto:sage [2008/09/21(日) 18:00:01 ID:???]
- >>137
>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか
おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。
PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
- 144 名前：nobodyさん mailto:sage [2008/09/21(日) 19:43:02 ID:???]
- > QIQなんてただのライブラリにすぎないんだから、
ライ・・ブラリ・・・？
> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ
|
 |
