プログラミング関係の話題。プログラミングコーナーを更新したとか、プログラミングの内容に踏み込んだ話とか。
PHPに、NULLにキャストする(unset)という構文があるのを知ったのですが、構文の存在意義がわかりません。
マニュアルには変数をunsetするような旨が書いてありましたが、実際にはそんなことはなく、値の評価結果がただNULLになるだけです。
ある値をNULLとして代入したい場合には意味があるかもしれませんが、「NULLとしての値」はそもそもNULLしか存在しないわけで、「ある値」なんか持ち出さなくともNULLをそのまま代入しても全く同じ結果が得られるわけです。
また、(unset)は言語構造であるがゆえに、「値」や「可変関数」のように扱うことができず、ポリモーフィズム的に値をNULLにするような使い方もできないわけです。
使い道は、果たして存在するのでしょうか。
カタカナをローマ字表記にするプログラムを作っていました。
アンパンマンDBでのページ名作成に補助的に使えそうです。
とりあえず、「完璧」より「それなり」を目指す方向性です。
PHPでフォントを使うための自分用ライブラリ作っています。
TrueTypeとかPostScriptとか極力意識せず使えるようにできたらいいなーと思っています。
とりあえず今できているのは、フォントファイルのフルパスの取得だけです。
レーダーチャートのプログラム、軸名まで表示できるようになりました。
本当は数値も表記できればレーダーチャートとして完成なのですが、この部分は個人的事情により作る気はありません。
レーダーチャートのプログラム、軸名が表示されない以外は完成しました。
さほど高性能ではありませんが、ちゃんと補助線も引けたりします。
レーダーチャートを描くPHP作っています。
当初はレーダーチャートの画像を生成するように作っていたのですが、大きな画像の一部としてもレーダーチャートを描けるようにしたいため、画像の生成は行わずに描画だけを行うようにしました。
検索文解析器、公開しました。
やってくれるのはツリーを作るところまでなのでその先の処理は自分で作らなければいけません。
検索文解析器微調整。
あまり使われなさそうな構文を削りました。
レーダーチャートを作るプログラムを作っていました。
とりあえずいろんな都合上PHPで。
いろんなグラフを書けると楽しいな。
検索文解析器、構文解析の都合上やたらと深くなりがちなツリー構造を単純化するようにしました。
これをやっておかないと最終的にSQL文を作るときに括弧だらけになってしまって見通しが悪くなるのです。
結局LL法の構文解析をまともに実装するやり方が理解できなかったので、拡張性だとか可読性だとか全く無視で、構文規則を直接関数に書き下して無理やり実装してしまいました。
とりあえずこれで検索ワードの構文ツリーが作れるようになったので、もうちょっと調整すればいろんなところに組み込めそうです。
日本がなんか世界一になったそうですね。
めでたいことです。
LL法なかなかわからんです。
集合論とかももうちょっと勉強せねばならなさそうです。
いつか頓挫したあのスクリプトよりは簡単だとは思うのですが…。
検索条件解析プログラム、字句解析解析中に追加の処理を入れられるようにしました。
これにより特殊な書式で書かれたものも解析できるようになりました。
そういえばライモンシティの連中、レベル20以上差があってもタイプ相性とその他条件次第ではなんとか勝てることもあるようです。
たとえばレベル38ガーメイル(虫・飛行)でレベル65ドレディア(草)を倒せたりとか。
もっとも、攻撃を4分の1に軽減してやっと1～2発耐える程度なので安定はしませんが。
PHPには、余計なコメントや空白を除去したソースを出力するオプションがあります。
それを使えばコードが短くなってコンパイル時間も含めたPHP実行時間の削減に役立つかなーと思ったのですが、あまり効果はないようです。
コメントや空白の除去は元々短時間で終わる字句解析にしか影響が無いためでしょうね。
実測してみたところ、むしろ空白除去版の方が処理時間が長くなる傾向が見られました。
おそらく改行が無くなったことにより切りのいいところで処理を切れなくなったからだと思います。
実際の字句解析の仕様は知らないのであくまでも根拠のない予想ですが。
数百KB以上のソースファイルのほとんどがコメントと空白なんて状態でもなければ目に見えて速くなるなんてことはありませんでした。
複雑な検索条件を構文解析するPHPプログラムを作成中です。
アンパンマンDBバージョン3用ですが、構文木まで作れればアンパンマンDBに限らずいろいろ応用が利きそうです。
PHPにはyaccとかlexみたいなのが見当たらないけど、少なくとも字句解析は正規表現でなんとかできそうです。
構文解析については、これも正規表現で頑張るか、昔頓挫した言語作成の延長線上でやるか、どちらかで頑張ることになりそうです。
やっぱりSmarty使うことにしました。
変数の割り当てやヘルパー関数の用意などを考えると、新規に自分でテンプレートエンジンを作っていると時間がかかってしまいそうなのです。
私が作りたいのは「スマートな設計のプログラム」ではなくて、「しっかり動くプログラム」なのです。
理想を追うあまりいつまでたっても何も動かなくては何の意味もないのです。
早速テンプレートをPHPコードに書き換え始めたわけですが、変数とか関数の扱いをあまり考えていませんでした。
テンプレートは関数を使って呼び出すことになるのでグローバル変数は使用不可。
テンプレートに変数を渡す方法を考える必要あり。
関数は常にグローバルスコープなので呼び出しに関しては何の問題もなし。
逆に、テンプレート用関数の定義をするときにどうするのかが問題。
このへんを充実させれば扱いやすくはなるかもしれないけど、今度は普通のテンプレートエンジンと何が違うのかってことになりかねない…。
アンパンマンDBバージョン3で、デザインとロジックの分離、デザインを複数用意したいという希望からテンプレートエンジンのSmartyを導入していたのですが、どうにも今回はSmartyにあまり利点がないような気がしてきました。
Smartyは高速なテンプレートエンジンですが、その高速化の根拠はテンプレートをPHPコードにコンパイルして、ほとんどの場合単にPHPファイルをインクルードするだけで済ませてしまいところにあります。
それだったらむしろSmartyなど間に介さず直接インクルードすればもっと速くて手っ取り早いわけです。
Smartyはデザインとロジックの分離のため、テンプレートファイル中では極力PHPコードを実行できないようにしてあります。
これはデザイナーが余計なコードを書いてプログラムをバグらせるのを防ぐという点では素晴らしいのですが、個人開発では単に自分一人が気をつければ済むだけの話です。
そもそも、PHPそのものが最初からテンプレート的な使い方をできるように設計されていて、Smartyはそのテンプレート的な使用法に特化したものに過ぎないのです。
そう考えると、Smartyはただのインクルードより設定が大変なだけでメリットがあまりないなぁ…と。
Tympoleは早くもただのガマガルになってしまいました。
進化すると日本語の名前に戻ってしまうのですね…。
手元においてあるPHPマニュアルに簡易的な検索機能をつけてみました。
基本的に関数を調べることが多いので関数名のリストを作って、検索エリアに入力すると関数名が自動補完されるようにしています。
Svg2Xaml、ストローク対応版公開しました。
実際に変化しているファイルは2つだけで、ほかのファイルについてはオリジナル版をそのまま使っています。
あと、付属しているテキストはライブラリそのものではないのでLGPLの適用外だと思われます。
TGWSAdminを修正しました。
RSSをアンパンマンDBの最新っぽい情報群に取り込むプログラムが、Twitter連携のときと同じように特定の状況下で働かないことがあったのです。
