dolem0.11.0のリリース

Read More

dolemの新しいVerのリリース。
今回のリリースでVerは0.11.0となった。

■dolem:ダウンロードページ
http://dolem.jp/?m=download


さて今回の0.11.0のリリースでは、0.10.1で行った修正を全てなかったことにする修正となってしまった。

Ver.0.10.1の主な変更点は、
クラスのnew演算子での呼び出しを禁止するための修正
という位置づけだったが、実際のところnew演算子は禁止にできていなかったことがわかった。

自分がメンバ変数とメンバ関数でのprotectedの挙動を違いを勘違いしていたところがあった。
いやはや恥ずかしい。


そして今回のVerUPでそれら全てのクラス群を(結果的にではあるが)全て上書きする修正になったのでVer.0.10.1のことは忘れてもらってもいい。
というか忘れてください



--
じゃあ気を取り直して。


今回のVer.0.11.0での変更点は以下のようになっている。
●BaseManagerクラスの改良。


このBaseManagerクラスとは、マネージャクラスの親クラスにあたるところでdolemの中で最もデリケートな部分。

このクラスがdolemの全てと言っても過言ではない。
このクラスの存在に比べれば他の要素はクソみたいなものだ。
それほど重要なクラスだ。


このクラス内のメンバ関数に「クラスプロパティ操作関数」なるものが存在する。
set()とかget()とかがそうだ。

これらと同列にclear()というものがある。

このclear()の挙動が昔からずーっと気に入っていなかった。

ただの'キー'を渡したときは要素はunset()されるのに対し、'キー配列'を渡したときはnullが格納されるというなんともちぐはぐな仕様になっていたのだ。

ちなみにキー配列とはキーボードの配列のことではない。
キー配列とはキーとなる文字列に区切り文字として'.'(ドット)を使うことで多次元配列を表現する、というもの。
これを便宜上「キー配列」と呼んでいる。

例えば
array('hoge' =>array('piyo'=>'aaa'))
というものをset()で格納したい場合は
$this->set('hoge.piyo', 'aaa);
これでクラスプロパティなるものにセットされる。

逆にクラスプロパティから取得したい場合は
print $this->get('hoge.piyo');
となる。


このようにして格納された要素を「破棄」するのにclear()が存在する。

しかし「キー配列」と「クラスプロパティ」いう特殊な構造をもつせいもあって先ほどあげたようにclear()の実装が不十分なものになってしまっていた。

この「unset()できない要素」の存在のせいで、やはり同じくメンバ関数の一つであるcount()の挙動を、むりやり辻褄をあわせるようなことをするハメになっていた。


しかし最近になってこの解決方法を思いついた。
まあそれはここで詳しくは書かないがeval()というPHP関数を使って実装する方法だ。

実はeval()はあまり推奨される関数ではない。
公式にもそのように書いてある。
特異な挙動をもつことから色々と問題になりうる関数だからだ。

でも使った。なぜか。

それ以外にもはや実装する方法が思い浮かばなかったからだ。
eval()を使うしかなかった。
しかしこれを使ったおかげで機能を実装できただけでなく可読性がかなりあがった。
やりたいことは実にシンプルだったのだ。



--
と、まあそんな感じでclear()の挙動が安定したものとなった。
またこれに関連してcount()の挙動も安定した。

ついでにset()やget()、その他のメンバ関数もリファクタリングを行いそれぞれコメント内容も充実させた。

このおかげで現段階でBaseManagerクラスはほぼつつくところがなくなった。

それほど完成度が上がった(と思っている)。


またこのBaseManagerクラスを継承している各マネージャクラスもこのタイミングで最適化を行った。
先述したようにBaseManagerクラスの完成度が実に理想的なものとなったので、継承している子クラスもさらにシンプルに書き換えることができることが予想できたからだ。

一応過去版で組んだものに影響が出ないように気を使って組みなおした。


ただし一点。


init()とinit_once()の実行順序が今まで自分が思っていたものとは逆の順番で実行されていたバグがあった。
この部分の修正のみ影響がありえる。

自分が確認したものでは、
DiagClass、ErrorClass、LoginCheckClass、ValidatorClass
を継承したクラスでその現象が起きる可能性があることがわかった。

例えばCookieクラスを例にあげると、
Cookieクラスではクラスプロパティに対して$_SESSIONの指定要素の参照渡しをしている部分がある。

このCookieクラスを継承して作った独自クラス内で別の$_SESSIONの要素を参照渡しすることにしていたとする。

これをする理由はクラスプロパティの独立性を確保するためだ。

しかし独自クラスで上書きしていたつもりが、先述した実行順序が逆に動作してしまうバグのせいで、実際は親となるCookieクラスでさらにあとから上書きされていたのだ。

つまり参照渡しがデフォルト状態の$_SESSIONの要素のものに上書きされていた。

このため、今回の修正分を過去リリースにしたものに適用すると、一部のCookieが消える(実際は正しい動作に戻るのだが)という結果をもたらすことがある。


と、まあ注意点としてはそんなとこ。


全体的にはリファクタリングしたことによって動作が安定したり、未実装だった機能が平等に使えるようになったり、派生クラスも可読性が上がったりと、全体性能の向上が主となっている。

今回の修正に関わるいくつかのテストも無事終えているので、あとは実際に稼動しているサイトに順次適応させてその様子を見ることで全工程は完了。




--
そろそろdolemを正式版に昇格することを視野に入れている。
しかしなんのかんので直すところがあったり、まだ最適化させていないクラスがあったりで中々思うようにいっていないのが現状。

dolemの前身となるcoreフレームワーク(非公開)は「誰にでもわかりやすい」というものに特化した作りを目指してつくった。
この背景には自身の開発速度向上のためというところが多分にあるが、それ以外にも、自分以外の人でも読みやすく触りやすいプログラムを組むことができるように、という思いがあった。
そしてその結果、当初の目的通り一定の成果をあげることに成功した。

チーム開発の速度は目に見えて向上し、また新人教育においてもそれなりに成果をあげることができた。
そういうこともあって良い物ができた、と少なからず自負していたところがあった。

そして今度はdolemとしてリリースすることを決め、それに合わせさらに簡素化するための手直しをした。
だが未だに見直せばまだまだ簡単に書ける部分があったりする。
見直せば見直すだけ見つけてしまう。

おかげさまで勘違いした自信を打ち砕かれたり、また勘違いし直したりというのを毎日繰り返している。

まあ本人は楽しんでいるのだが。



さて今後の作業予定としては、
・Mailクラスの実装
・Sessionファイルの保存フォルダの分割管理の実装
を予定している。

個人的にはSessionファイルの保存フォルダの分割管理の実装がとてもわくわくする。
一つのフォルダで管理するよりも速度は向上しそうだし、FTPクライアントソフトで一覧表示する動作にもかなりの改善が見込めるからだ。
以前からその構想はあったものの、必要に迫られることも多くなかったので着手してなかったのだが、ようやくやってしまおうという気持ちになった。




…うん、これをすると正式版のリリースにはもうしばらく時間がかかりそうだ。

正式版のリリース後にすべきかなあ