普通に使う分にはやっぱ2重が多いな。3重がたまに。
設定項目とか、複数のカラムがあってキーに関連するデータを
取り出したいような場合はそれ用の汎用的なクラス作って管理してる。

PHP自体が富豪プログラミングの集大成みたいなもんだからな
入るんだから入れちゃえばいいんじゃね？みたいになっちゃう
CとかJavaで仮に同事ができるとしても、
それやったら目に見えてメモリバカ食いするのが解って怒られちゃうけど
PHPだと間違って動いちゃうのでなんともしがたい

間違って？

最近だと
calender[month][week][day]
なんてのを作って
smartyに丸ごと渡して、表示してた

この先の処理で使わない変数をunsetする事もあるけど
ＣやJavaと違って意味薄いしなあ

よく[month]みたいに書く奴いるけど
['month']だろ
monthが定数だったらどうすんだよ

定数は普通大文字で書くだろ

お前は何を言ってるんだ

大文字でしか定数が設定できないから問題ないってのなら解るが
それは大文字で設定するのが普通というのとは大きく意味が異なると思うぞ
途中でdefine('month',1)なんて追加されたら恐ろしいことになる

だからあれほどE_NOTICEを無効にするなと言ってるだろうに
何度も言うがNotice切ってる奴はもれなくカス

[month]って書いたってエラー出ないだろ？
エラーじゃないんだから何の問題もないのに
自分が勝手に決めた規約を押しつけるのは良くない

残念ながらつい50秒前に論破されてますよ

>>809
pear使うとエラーが出まくるんだよ

え？いまなんて？

もうちょっと大きな声でたのむ！

>[month]って書いたってエラー出ないだろ？
>[month]って書いたってエラー出ないだろ？
>[month]って書いたってエラー出ないだろ？
>[month]って書いたってエラー出ないだろ？
>[month]って書いたってエラー出ないだろ？

noticeは確かにエラーではないけどｗｗｗ

if($a=0) {

みたいな間違い方だよな。

pearは使い物にならない

5.3まだー？

scandirで..と.が入るのが不便

つglob

ファイルのロックって難しいです。
LOCK_EX で排他ロック中のファイルはreadfile関数で読み込めるんでしょうか・・・？

試してみればいいじゃん
アドバイザリロックでぐぐれば想像付くと思うけどさ

なんでもかんでも

「試してみればいいじゃん」

しかいえないやつは火炎放射器で消毒すべき。

readfile()は読み込み不可ならすぐfalse返すんだったと思うが違うのか？
モダンな処理系じゃないならしーらない。

>>824
　 /＼＿＿_／＼
／　⌒　　　⌒ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　消毒、試してみればいいじゃん
|　　　ト‐＝‐ｧ' 　 .::::| 　　 ＼＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

結局読めたり読めなかったりするってことか

しょういうこと

実験したらロック中でも読めるみたいなんだけど、
どういう条件で読めなくなるの？

それはロックできてない

ロックの魂を理解していない

http://ascii.jp/elem/000/000/050/50590/img.html

試してみたらwinだとロック中に読めないな。腐ってやがる

is_null と $hoge === null って
どちらが速い或いはメモリ消費量が少なかったりするのかね？

is_null()だと関数呼び出しのオーバーヘッドありそうだけどどうだろ

っていうか is_null ってどのみち $hoge === null 返すだけでしょ？
可読性が多少良いくらいで関数のオーバーヘッディングがワンステップ確実に増えるでしょ。

じゃis_nulは何のためにあんの？

自分のコーディングを信用できず、標準関数だと安心できる人のため。

===を理解してない人にもわかるようにじゃねｗ

コンパイラ通すような言語だとこういうのはどっちで書いてもコンパイル時の最適化で
実行ファイルでは全く同じ処理するように置き換えられたりしそうだけど
PHPだと無理なんだっけ？中間コードみたいな

>>836
is_nullは組み込み関数故、C言語のコンパイラ／リンカレベルで最適化されているはず。

そのため、$hoge === nullを比較するopコードと、組み込み関数を呼び出すopコードの違いと考えると、そこまで大きな差は生まれないような気がする。

実際PHPのソース拝んだ訳じゃないから、適当な思いつきだけど

>>839
Zend optimizerとかeAcceleratorのoptimizerオプションをonにすれば、少しは最適化されるかもね。
あとは、大幅に改善されると噂されるPHP 6(Zend Engine 3)に乞うご期待ってところ？

なるほどねー
まぁそのあたりの差が顕著になるようなものをPHPで作ること自体ありえない気もするけどなｗ

マニュアルのユーザノートにベンチあったぞ
実装意図はis_*軍団のインテグリティのためだろう
型判定のシリーズがあるから

まあよりカオスになっとる気もするけどな

確かに、いっそのことis系は最低限必要な物以外は全部なくなった方が迷わなくて済むな。

組み込み関数でも演算子に比べればオーバーヘッドがあるだろ。

どうせやること同じなんだし、どっち使うかなーとか考えなくてすむしなｗ

>>784
CIにのせたわけじゃないけど
Posqlってメソッドが充実してるし使えると思うぞ。
小規模なものならな。
PHP構文が使えるのは楽だ

へー
世の中いろいろな変わり種があるもんだな

>>839
高級言語とレTゎ抽象化も重要だょね
論理的ﾚこ同等でょリ高速ﾅょ機能を求ぬﾅこら才一ﾉﾚぁセンブラに行き着ぃTしまぅょ

文字化けしてるのかと思ったがな。

848の書き込みは、これはこれで正解なのかな。