packagist内でlaravelの定義が巨大すぎて困る
ここでぼやいても誰にも伝わらない気がするけど、一旦吐き出しておきます。 事の経緯 私は https://packagist.org のミラーサイト packagist.jp を運営しています。 スクレイピングのプログラムがバグっていて、1ヶ月に一度ぐらい古くなったファイルを掃除して回る定期作業があるのですが、その中で妙にlaravel関連のパッケージ情報が巨大であることに気づきました。 例えば、私のMacのローカルキャッシュに残っているパッケージ情報をファイルサイズでsortすると、上位は全てlaravel関連のものになります。これらはpackagist.jpの中にミラーリングされているファイルと全く同じものです。 1971473 p-provider-2016-01.json 2058474 p-provider-2016-04.json 3687200 provider-illumin
switch文を使ってはいけない
昔Qiitaで書いた内容なんですが、PHPのswitch文は悪名高い「==」演算子で比較を行います。 <?php switch (true) { case 0: echo '数字の0'; break; case '0': echo '文字列の0'; break; case '0.0': echo '文字列の0.0'; break; case true: echo '真偽値のtrue'; break; } このコードは「文字列の0.0」を出力します。大変分かりにくいですね。 この点はif ... elseif ...を使えば解決するんですが、switchで書きたくなるようなコードをelseifにするとおそらく読みにくくなるでしょう。 ではどうするか。 正解はオブジェクトのポリモーフィズム(多態性)機能を使うことです。 といっても、多態性で調べて出てくる記事とか書籍に関しては抽象的な説明が多い
PHPの名前空間の効果的な使い方を考える
PHPは5.3から名前空間が導入され、名前の衝突を避けるため長いクラス名をつけることから解放されました。しかしながら、名前空間を使ったコードは、名前空間を使っていないものに比べて本当に読みやすくなっているのでしょうか？ ここで例を挙げます。PHPの良質なソースコードと言えば、私はZend Framework(ZF)やSymfonyを思い浮かべるのですが、ZFのとあるクラスの冒頭を見てみましょう。 https://github.com/zendframework/zf2/blob/master/library/Zend/Mvc/View/Console/RouteNotFoundStrategy.php <?php /** * Zend Framework (http://framework.zend.com/) * * @link http://github.com/zendframewo
それでもPHPにfinallyが必要な理由
PHP Conference 2012で知ったのですが、PHP5.5にはfinallyが搭載される見込みだそうです。 搭載されるのはいいのですが、昔、「PHPにfinallyはないけどデストラクタがあるよ」と題してfinally不要説を書いたことがあるので、もう少し考察を行ってみたいと思います。自分で自分に反論を書いてるのもアレなんですけど。 ※RFCは追いかけてなかったので、本記事は想像で書いています。ツッコミください。 finally不要説 私が主張した内容を要約するとこんな感じです。 finallyの主な用途はファイルのクローズやDBの接続断などの「後始末処理」である。 後始末はデストラクタで行うこともできる。 PHPではデストラクタの動作が保障されている。（参照カウントによるGC） ゆえにデストラクタを正しく使えばfinallyは不要。 具体例を出すと、finallyのRFCでは例
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
