トップページ⇒php
1001コメント368KB

Zend Framework Part4

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2010/02/09(火) 22:21:24ID:???
公式
http://framework.zend.com/

マニュアル
http://framework.zend.com/manual/ja/

翻訳状況
http://mikaelkael.dyndns.org/checker/language/details/lang/ja
http://framework.zend.com/wiki/display/ZFDEV/Japanese+(Nihongo)

バグ報告
http://framework.zend.com/issues/secure/Dashboard.jspa

API
http://framework.zend.com/apidoc/core/

前のスレッド Zend Framework Part3
http://pc11.2ch.net/test/read.cgi/php/1239320100/
0552nobodyさん2010/10/23(土) 00:37:26ID:???
>>549
deleteActionの最後で_foward()か_redirect()すればいい。

画面を描画したくないなら、viewHelperを無効にすればいい。
http://framework.zend.com/manual/ja/zend.controller.action.html
0553nobodyさん2010/10/23(土) 00:50:00ID:???
>>540
>>543
マニュアル読んで気がついたが、

「自分のウェブアプリケーション用に便利な機能を実装していく一方で、
同じような前処理やちょっとした処理をあちこちのコントローラで書いているといったことはありませんか？
そのような場合は、Zend_Controller_Action を継承した共通基底コントローラクラスを作成し、
共通処理をそこにまとめていくようにしましょう。 」

と明記されてるね。
http://framework.zend.com/manual/ja/zend.controller.action.html
0554nobodyさん2010/10/23(土) 02:16:34ID:???
>>540
＞無かったらユーザがActionだけ書いて動くわけないでしょ
動く。ルーティングを行う為の基底コントローラ(ZFではDispatcher)側の実装の問題だ。

MVCの考え方とやらに従うのであれば、Action以外にもCに実装するべきロジックは多々ある。
それを基底クラスに書くのか、別クラスに書くのか、その実装方法自体はMVCの思想には含まれていない。
05555492010/10/23(土) 02:37:46ID:???
>>551,552
お恥ずかしい。ありがとうございました
0556nobodyさん2010/10/23(土) 07:14:23ID:???
継承ってすればするほど重くなるのかな？
ある程度はキャッシュされるとしても体感しない程度に重くなってる？
0557nobodyさん2010/10/23(土) 10:09:58ID:???
>>554
Dispatcherはコントローラだろ　何言ってんだ
0558nobodyさん2010/10/23(土) 10:58:26ID:???
>>557
だからCに関するロジックであれば、Zend_Controller_Actioｎに実装しようが、Dispatcherに実装しようが、他のクラスに実装しようが、
MVC思想とは関係無いんで >>540 の発言の意味がわからねーんだわ。
0559nobodyさん2010/10/23(土) 11:12:25ID:???
>>558
>>無かったらユーザがActionだけ書いて動くわけないでしょ
>動く。ルーティングを行う為の基底コントローラ(ZFではDispatcher)側の実装の問題だ。

Cに関するロジックが無くても動くってどういうこと？

0560nobodyさん2010/10/23(土) 11:31:06ID:???
>>559
Zend_Ctonroller_ActionにAction以外のメソッドが無くても、
Dispatcherなり、どこかしらに実装しておけば動くって事。

>>540ではAction以外を定義するのはMVCに反すると、
意味不明な書き込みがあったが、Cに関するロジックであれば何処に書こうが何ら問題は無い。

むしろ共有ロジックはActionクラスに書くことをZFは推奨(>>553)している。
0561nobodyさん2010/10/23(土) 11:56:02ID:???
>>560
>Zend_Ctonroller_ActionにAction以外のメソッドが無くても、

Zend_Controller_Actionには_forwardや_getParamや_redirectなど
たくさんAction以外のメソッドがあるように見えるが・・・？
0562nobodyさん2010/10/23(土) 12:03:59ID:???
>>561
話ループしてるし何が言いたいかわからん
>>536 からの流れ読め
0563nobodyさん2010/10/23(土) 18:28:37ID:???
>>556
バイトコードキャッシュとか使ってない環境だと
どのくらい影響あるんだろうね。

PHPでもJavaみたいにInterface多用して設計したいけど、
実行時の無駄な処理が気になる。

本番環境ではInterfaceのチェック処理を
無視する設定とかあるのかね？

ZFでも結構多用されてるってことは、ほとんど影響ないのかな？
0564nobodyさん2010/10/23(土) 18:33:37ID:???
>>562
自分の誤りをごまかさないでほしい
0565nobodyさん2010/10/23(土) 19:07:53ID:???
>>562 >>564

君たち話がかみ合ってない。

要はZend_Ctonroller_Action継承した基底Controller作って、
共通の処理はそこに実装。
※出来ればinit()やらpreDispatch()の中だけで済ませる
それを継承した各Controllerで個別に呼び出したい処理は
ActionHelper作る。

でいいんじゃない？
オーバーライド用に容易されてるメソッド以外に、
各ControllerでAction以外のメソッド書かないといけない必要性って
ほとんどないような。手っ取り早いけど。
0566nobodyさん2010/10/23(土) 19:56:33ID:???
>>565
ヘルパーブローカを使うとPDTでコード補完出来ないのが不便なんだよなぁ、
どこかしらに @return アノテーション付でgetter定義しておかないとならんし･･･

自分の場合、

プロジェクト基底コントローラ
　→ アプリケーション基底コントローラ
　　→　モジュール基底コントローラ

をそれぞれ継承して作っておいて、
Controllerに共通プロパティやショートカットメソッド定義してるわ。
0567nobodyさん2010/10/23(土) 20:19:28ID:???
>>565
＞各ControllerでAction以外のメソッド書かないといけない必要性って
＞ほとんどないような。手っ取り早いけど。

Controller固有のロジックやプロパティを外部化する必要性もほとんど無いからね
臨機応変に最適な手法を取ればいいと思うよ

無闇に肥大化させるのは好ましくないけれど
将来Zend_Controller_Actionと競合するかもしれないという理由で
実装コストを上げてしまうのは同意し辛いな
0568nobodyさん2010/10/24(日) 00:52:09ID:???
>>563
ベンチで測ってみろよそれくらい
0569nobodyさん2010/10/24(日) 12:51:40ID:???
プラグインからアクションヘルパーを呼ぶ方法ってありますか？
アクションコントローラを作るたびに同じアクションヘルパーを呼ぶ記述書くより
プラグインに共通で書きたいと思ったのでやり方を探しているんですが見つけられません。
0570nobodyさん2010/10/30(土) 15:35:08ID:CCVX4Qsq
各クラス（コントローラ）の中のアクションがありますが、
これを再利用する方法ってないんでしょうか？

というのは、たとえば入力フォームのアクションだったらバリデート処理が書いてるけど
同じようなフォームの時、ほとんど中身変わらないのに同じようなのをもう一つ書くのが面倒なんです
具体的に言うと nikki_addアクションとnikki_rewriteアクションとか。。
新規登録時でも書き換え時でもバリデータは同じだけど、アクションを２つに分けると
中身同じなのにもう一つ書くことになって面倒くさいと…
何か良い方法ないですか？
0571nobodyさん2010/10/30(土) 15:55:15ID:???
バリデート込みのフォーム定義をアクション外に括り出せばいい
0572nobodyさん2010/10/30(土) 15:55:33ID:???
>>570
難しく考えなくていいよ。
コントローラにnikkiValidateメソッドを作って、
nikki_addとnikki_rewriteから呼び出せばいい。

もしそれが気持ち悪いのであれば、Nikkiクラスでも作るなりして、共通処理をまとめればいい。
0573nobodyさん2010/10/30(土) 15:57:20ID:???
アクションにバリデート書くとかMVCの意味なくね？
0574nobodyさん2010/10/30(土) 16:12:06ID:???
MVCの概要を説明する文書がどれもわかりづらいっつーか、
不明瞭な書き方するからいけないんだよね。

モデルに書けそうなロジックは全部モデルに記述するように試みればまず間違いない。
0575nobodyさん2010/10/30(土) 16:22:23ID:???
コントローラ内で局所的にしか使わないようなロジックであれば、まぁいいんでない。
汎用性とか徹底したMVCとか考えるとキリが無い。

要はケースバイケース。
コストに見合った実装すればいいよ。

RDBだからとテーブルを無闇に極限まで正規化しないだろう？
0576nobodyさん2010/10/30(土) 18:06:00ID:???
>>575
いやまあ、そうなんだけど、そういうと馬鹿はコントローラに全部書いちゃうから。
コントローラに書くことなんてほぼ無いのに。
0577nobodyさん2010/10/30(土) 18:44:20ID:CCVX4Qsq
>>571-576
おおー、ありがとうございます。
そうですね！共通利用するんだから両アクションから呼び出せばいいんだ
なんで思いつかなかったかなー
ありがとうございました
0578nobodyさん2010/10/30(土) 23:54:53ID:???
コントローラって名称に毒され過ぎだよね。
極端な例だけど、以下のようにロジックがきっちり分別されていれば、
同クラスだろうが、同ファイルだろうがMVC実装は可能。

class Application
{
public function controller() {}
public function model() {}
public function view() {}
}
0579nobodyさん2010/10/31(日) 00:48:20ID:???
えっ
0580nobodyさん2010/10/31(日) 02:04:35ID:???
デザインパターンに実装方法は定義されてないからね
ファイル、クラス、メソッド、好きな方法で区切ればいい
0581nobodyさん2010/10/31(日) 02:12:58ID:???
お前は何を言ってるんだ
0582nobodyさん2010/10/31(日) 02:23:02ID:???
>>581
何か間違ってた？
0583nobodyさん2010/10/31(日) 04:11:44ID:???
いやそもそも同じクラスに違う目的のものを突っ込むのが
オブジェクト指向的に間違いなわけで
0584nobodyさん2010/10/31(日) 04:36:27ID:???
ああクラス名を MVCにした方が解りやすかったかな。
OOP的にも、MVC的にも問題無いと思うよ。
絶対やらんけど。

class MVC
{
public function controller() {}
public function model() {}
public function view() {}
}

0585nobodyさん2010/10/31(日) 04:46:01ID:???
クラス名がMVCってその時点でもう破綻してるだろｗ
自動車をオブジェクト指向で表す場合に
EngineWheelStealingってクラス作るようなもんだぞｗ
0586nobodyさん2010/10/31(日) 04:53:18ID:???
ﾜﾛｽ
0587nobodyさん2010/10/31(日) 05:44:37ID:???
普通は複数の機能が乗るわけでそうなったらどうすんだ？
AMVCとかBMVCってクラスができるのか？
それじゃmodelとcontrollerまで対じゃないと破綻するよな
それともa_controller() b_controller()って増やしていくのか？
0588nobodyさん2010/10/31(日) 13:34:07ID:???
えっ
0589nobodyさん2010/10/31(日) 14:02:42ID:???
例えの話に何ムキになってるの･･･怖い･･･

>>585
Car extends EngineWheelStealing
0590nobodyさん2010/10/31(日) 14:57:07ID:???
・・・はい？ｗ
0591nobodyさん2010/10/31(日) 15:00:09ID:???
>>589
おまえすげーな
スパーハカーだなｗ
0592nobodyさん2010/10/31(日) 15:04:14ID:???
>>578ってオブジェクト指向もMVCもZendの使い方も一つも解ってないんだろうな
0593nobodyさん2010/10/31(日) 15:04:24ID:???
理解の範疇を超えると煽る事しか出来ないです＞＜
0594nobodyさん2010/10/31(日) 15:10:21ID:???
自分はあんまりオブジェクト指向原理主義者じゃないけど、
is-aとかhas-aとかなんかそういう基本的なところのセンスがとても悪いと思う。
0595nobodyさん2010/10/31(日) 15:10:38ID:???
これはひどい初心者
0596nobodyさん2010/11/01(月) 12:15:19ID:???
class DqnCar extends Car implements AeroParts
0597nobodyさん2010/11/01(月) 20:53:23ID:???
発想は面白いがそれは英語的にもOOP的にも違うなｗ
0598nobodyさん2010/11/01(月) 21:21:37ID:???
このスレは独創的なオブジェクターが多いなｗ
0599nobodyさん2010/11/01(月) 22:07:25ID:???
オブジェクト指向っつっても、主観次第で変わるからなぁ･･･
0600nobodyさん2010/11/01(月) 23:04:15ID:EIHh7aSp
zendframeworkで、携帯とPCでviewを分けたい場合
どの部分で、振り分け処理を記載してらいいですかね？
0601nobodyさん2010/11/01(月) 23:40:28ID:???
基底コントローラやinitメソッドからの呼出でいいんじゃない？
0602nobodyさん2010/11/02(火) 00:02:44ID:yTnsmEW2
>601

ipで、振り分けようかと思ってるんですが
PEAR::Net_IPv4を使って、Bootstrap.phpで使用していいか悩んでます。
その後の、viewの振り分けもわからないですけ。。。
0603nobodyさん2010/11/02(火) 00:03:15ID:???
俺は邪道だと言われるかもしれないけど、拡張子を変えてる。
パソコンはphtml野間まで、携帯はhtmlに設定。

同一アドレスで同一サービスが提供可能に。
0604nobodyさん2010/11/02(火) 00:47:33ID:???
>>602
Bootstrapで携帯かPCかを判別して、
何らかの方法(FrontController、Request、Registry、etc)でControllerに渡せばいい。
振り分け方法はケースバイケースだが、面倒でなければ携帯用のViewクラスを用意するのが望ましい。

>>603
何故に拡張子？
テンプレートディレクトリで切り分けた方が良いんじゃね？
0605nobodyさん2010/11/02(火) 01:07:52ID:???
bootstrapなんでもありだな
0606nobodyさん2010/11/02(火) 01:28:32ID:???
本来Bootstrapはアプリケーションを初期化したり、
状況に応じて設定を変更したりする為のものだからな･･･

可能なら MobileBootstrap.php を作って、
リクエストを受け取る index.php でip判別して、Bootstrap自体を振り分ける方法もありかと。
0607nobodyさん2010/11/02(火) 01:44:20ID:???
俺は同じコントローラなのがかなり不便だからコントローラから分けてる。
表示内容とか含めてPCとモバイルでコントローラが同一でいいなら
>>603の方法を使うと思う。
0608nobodyさん2010/11/02(火) 02:22:33ID:???
controllerの親クラス作ってそこでやってるわ俺
0609nobodyさん2010/11/02(火) 11:12:23ID:???
俺もそれだわ、だってPCと携帯で同じアクション使ったりしてるもん。
今見たらinit()でこんな事してた
$this->_helper->layout->setLayout('mobile');
$this->view->setScriptPath(APPLICATION_PATH.'/views/scripts-mobile');
0610nobodyさん2010/11/02(火) 11:43:50ID:???
>>609
それが一番美しいやりかたかと思う。


ただしinitは複数回呼ばれる可能性があるので、気になる人は初期化済か否かのチェックをいれるなりした方が良い。
06116092010/11/02(火) 15:59:56ID:???
よく似たのがあると思ったら、なんと以前このスレに俺が自分で質問してるじゃあないか
誰も返事してくれてないしｗ なんかちょっと恥ずかしいぞ。 >>264
bootstrapでレイアウトを手動初期化する方法も書いてある
0612nobodyさん2010/11/03(水) 01:33:55ID:???
http://devzone.zend.com/article/12724-Zend-Framework-1.11.0-FINAL-Released

>>600
つZend_Http_UserAgent
いいタイミングｗ
0613nobodyさん2010/11/03(水) 04:59:30ID:???
Zend_Http_UserAgentってIPアドレス判別とか出来るのかね･･･
クラス名も微妙に輪っか利辛いなぁ・・

Zend_Mobile_Deviceとかで良かったんじゃね？
0614nobodyさん2010/11/03(水) 07:58:18ID:???
IPで判別とか日本ローカルなんだからお前らが作れ
0615nobodyさん2010/11/03(水) 11:22:15ID:???
Java屋です。次案件でzend frameworkを使った開発をするのですが
hibernateやiBatis, S2Daoのような標準的なORMはいくつかあるのでしょうか？
0616nobodyさん2010/11/03(水) 11:26:43ID:???
なんでぐぐらんの？
06176152010/11/03(水) 11:35:27ID:???
>>616
ぐぐってから聞いてる？
自分はぐぐってから書いてるよ。
0618nobodyさん2010/11/03(水) 11:40:14ID:???
じゃそれで分かるじゃん
0619nobodyさん2010/11/03(水) 11:47:12ID:???
ググってわかったら書かないでしょ
0620nobodyさん2010/11/03(水) 12:00:20ID:???
そうかすまんかった。まぁ頑張ってくれ。
0621nobodyさん2010/11/03(水) 12:09:09ID:???
おお。応援ありがとう。頑張るわ
0622nobodyさん2010/11/03(水) 12:52:45ID:???
ORMは山ほどある。
標準的が何を示すのか不明だがZFならZend_Db_Tableあたりだ。
0623nobodyさん2010/11/03(水) 13:06:02ID:???
そもそもhibernateやiBatis, S2Daoは標準的なORMじゃないので
0624nobodyさん2010/11/04(木) 00:39:38ID:1iy2rlVw
質問します。たとえば日記のアプリを作るとき
localhost/diary/edit/y/2010/m/11/d/1　って形で入力画面（editアクション）を開くとします。

そうすると、まずこの時点でパラメータが日付にふさわしい型か
パラメータチェックする必要があると思うんですが、その処理を外部化したいんです。
↓こんな感じで（diaryコントローラ）
public function init(){
　require('paramChk.func.php');//検証機能の外部化
}
public function editAction(){
　$param=$this->getRequest()->getUserParam();
　$checkAry = array(
　　　　　　array($param['y']=>array('required', 'numeric'),//パラメータyが必須かつ数値かチェック
　　　　　　array($param['m']=>array('required', 'numeric'),
　　　　　　array($param['d']=>array('required', 'numeric')
　　　　　　);
　paramChk($checkAry);
}

このとき、実際の検証用外部関数paramChk()の中でエラー（不正の発見）があったとき、
エラーコントローラにリダイレクトさせたいんですが
function paramChk($ary){
　//チェック処理省略
　if($err)　return $this->_redirect('/error/pt/paramerr');
}
とするとエラーが起きます（Using $this when not in object context in /var/www/application/inc/paramChk.func.php）
どうしたらいいんでしょうか？　検証処理は外部化しつつ検証エラーの時のリダイレクトまで実装したいです。
意見よろしくお願いします
0625nobodyさん2010/11/04(木) 00:54:38ID:???
エラーの時返り値返せばいいのでは
0626nobodyさん2010/11/04(木) 01:10:04ID:???
>>624

・editAction側でリダイレクトさせる方法
if (!paramChk($checkAry)) $this->_redirect('/error/pt/paramerr');

・paramChk側でリダイレクトさせる方法1
paramChk($checkAry, $this); // $this(コントローラを引数で渡す)
function paramChk($ary, $controller){};


多分、前者の方が好ましい。
(paramChkもグローバル関数では無く、何らかのクラスに隠蔽すると尚良い)
0627nobodyさん2010/11/04(木) 01:31:00ID:???
コントローラを外部関数に渡すとか初めてみたｗ
0628nobodyさん2010/11/04(木) 02:11:43ID:???
redirect処理含めて外部関数に隠蔽したいなら、なんらかの方法で渡すしか無いだろうｗ
06296242010/11/04(木) 11:44:09ID:???
>>625-626
ありがとうございます。
なるほど、確かにエラーの時にfalse返してコントローラでリダイレクトの方が
あとあと便利そうですね！
「if (!paramChk($checkAry)) 」こういうの思いつかないのでホント聞いて良かったです

＞paramChkもグローバル関数では無く、何らかのクラスに隠蔽すると尚良い
これはなぜですか？
0630nobodyさん2010/11/04(木) 16:29:59ID:???
>>629
＞paramChkもグローバル関数では無く、何らかのクラスに隠蔽すると尚良い
＞これはなぜですか？
他にparamChkという関数が存在していると不具合が出ちゃうからね。
値を検証するクラスを別に作り、必須や数値チェックするのもそちらに外部化する方が見通し良くなると思うよ。

以下簡単な例

・Controller側
$diary = new Diary($param['y'], $param['m'], $param['d']);
if ($diary->isValid()) $this->_redirect('/error/pt/paramerr');

・Diaryを処理するクラス
class Diary{
private $_param = array();
public function __construct($y, $m, $d) {
$this->_param['y'] = $y;
$this->_param['m'] = $m;
$this->_param['d'] = $d;
}

public function isValid() {
// $this->_param に正常な値が入っているかチェック
return true;
}
}
0631nobodyさん2010/11/04(木) 20:13:18ID:???
俺はパラメータチェックはアプリケーションではなくアクションの仕事だと考えて

アクション内で
$this->reqParams('y', 'm', 'd');

基底コントローラ内で
public function reqParam() {
foreach (func_get_args() as $arg) {
if (!$this->hasParam($arg)) {
throws Hogehoge_Parameter_Exception();
}
}

みたいなことやってたよ
0632nobodyさん2010/11/04(木) 21:06:11ID:???
Javaやってた自分からすると、メソッドの中で
func_get_argsとか、array渡してextractとかやって
可変引数を扱うのにいまだに馴染めないんだけど
これらってバッドノウハウじゃないのかな？
0633nobodyさん2010/11/04(木) 21:17:13ID:???
>>632
可変引数はPHPにおいてはバッドノウハウでは無く、割と一般的なテクニックかと。
個人的にはfung_get_args()よりarray渡しを使うけど。

＃extractは使う場面は思い浮かばない。
0634nobodyさん2010/11/04(木) 21:18:32ID:???
extractとfunc_get_argsを同列に語るのは
さすがにPHPの経験不足が露呈しすぎだぞ
0635nobodyさん2010/11/04(木) 22:32:56ID:???
>>634

というのも、 >>632 で書いたのもスレチなわけではなくて
ZFのViewHelperのForm**** 見てたらどれも

public function form****($name, $value = null, $attribs = null, $options = null, $listsep = "<br />\n")
{
　$info = $this->_getInfo($name, $value, $attribs);
　extract($info); // name, value, attribs, options, listsep, disable

みたいになってて、こんなのどうやって呼び出すんだよ…って思ったんだよ。。
こういうのってPHPでは無茶なやり方ではないのかな？
まあ、フレームワークでやってるってことは一般的なのか・・・
0636nobodyさん2010/11/04(木) 23:16:22ID:???
その例では$name, $value, $attribsを元に戻してるだけ
引数が限られているなら危険性もないし、逐一コード書くより統一性が取れて開発効率も上がるから使ってるんだろう
06376242010/11/05(金) 01:38:03ID:FPhbRDb9
>>630
＞他にparamChkという関数が存在していると不具合が出ちゃうから

なるほど、納得出来ました。paramChkクラスを作ってみます。

＞if ($diary->isValid()) $this->_redirect('/error/pt/paramerr');

これは、ifの()の中ってこれで良いんですか？
trueを返す条件でエラーのリダイレクトにならないですか？
自分凄い勘違いしてるのかな


他の人の意見も勉強してみます
ありがとうございました
0638nobodyさん2010/11/05(金) 02:12:03ID:???
>>637
＞＞if ($diary->isValid()) $this->_redirect('/error/pt/paramerr');
＞これは、ifの()の中ってこれで良いんですか？

ごめん。　if (!$diary->isValid()) だね。
06396242010/11/05(金) 02:50:10ID:???
>>638
おお、良かったです
こんな時間にありがとうございました
0640nobodyさん2010/11/05(金) 09:45:33ID:???
array渡しはJavaScriptでもよくあるし
JSONやXMLとの親和性もいいんじゃないか？
0641nobodyさん2010/11/05(金) 16:52:21ID:???
オーバーロードが出来ない言語ではよくある手段だね。
0642nobodyさん2010/11/05(金) 19:40:31ID:???
ZF 1.11来たな
http://sourceforge.jp/magazine/10/11/05/0641258
0643nobodyさん2010/11/05(金) 20:48:27ID:???
>>641
単に引数の個数が可変の時に使ってるだけじゃね？
0644nobodyさん2010/11/06(土) 00:53:16ID:???
>>643
普通は無尽蔵に可変なら配列で渡すし、
引数の数や型よって処理が変えたいのであればオーバーロードする。

PHPはオーバーロードが無いから仕方無い。
0645nobodyさん2010/11/06(土) 01:07:38ID:???
>>644
extractとfunc_get_argsのどっちの話？
0646nobodyさん2010/11/06(土) 01:11:09ID:???
>>645
func_get_argsの話。
単に不特定多数の値を渡すだけなら配列渡しの方が見通しが良い。
func_get_argsは、引数の数をチェックして振る舞いを変える為にあるイメージ。(疑似オーバーロード)

まぁ好みの問題だろうけど。
0647nobodyさん2010/11/06(土) 01:38:52ID:???
いや不特定多数の引数を渡す時のための関数だともうよ
0648nobodyさん2010/11/06(土) 02:46:56ID:???
不具合の温床になるから、
配列渡しの書き方を省略したいだけなら array() でくくった方が良いと思う。
IDEとの相性も悪いし。
0649nobodyさん2010/11/06(土) 02:49:53ID:???
不具合ってどんな不具合？
0650nobodyさん2010/11/06(土) 03:05:36ID:???
何故オーバーロードという概念があるか考えれば解るよ。

逆にarrayで囲わない理由は何だろうか？面倒だから？
0651nobodyさん2010/11/06(土) 03:08:01ID:???
なんだよ例出せないんじゃん
■ このスレッドは過去ログ倉庫に格納されています