戻る


2014/01/23 14:16

イベントハンドラは基本的に複数設定できるようにするべきかもしれない。

現在の状態では、イベントハンドラは1つしか付けられないようになっている。

理由としては、簡単に言えばめんどかったからである。

1つであれば、イベントハンドラが設定されているかいないか、しかない。

イベントハンドラを解除する、という処理をするなら、設定されているものがあればそれを削除すればいいだけの話だ。

これが複数となるとそうはいかない。どのイベントハンドラを削除するのか、とかいう話になってくる。

そうなると、イベントハンドラに結び付く情報がどうとかいう話になってきて、なかなかめんどくさい。

その辺の理由から、1つだけ付けられる形にしてきたわけだけど、1つしか付けられないとなると、複数の箇所からイベントハンドラを設定するような感じになってくると、非常に使いにくくなる。

イベントハンドラを設定する、とはつまり、既存の設定を上書きしてしまうことになるわけだ。これはよくない。上書きされた側は、意図せずイベントハンドラの設定が解除されることになる。

これで問題が発生しないとはとても考えられない。

とかいうのが、ログ関係のイベントをどうするかとか、ライブラリの依存関係がどうとか考えていたら出てきた。

ログライブラリは、出力するために文字コード変換が必要になるので文字列ライブラリに依存しているんだけど、それではよくないと思ったのだ。

それをすると、文字列ライブラリがログライブラリに依存できず(循環参照になるため)、文字列ライブラリからログの出力ができなくなるのだ。

そこで、ログライブラリは文字列ライブラリに依存させず、ログライブラリと文字列ライブラリの双方に依存する、ログ出力ライブラリというのを用意することを考えた。

ログライブラリはログを受け取るインターフェースと、ログを受け取った時にイベントハンドラを呼び出すだけにして、ログの文字列変換などは行なわない。ただの橋渡しだ。

ログ出力ライブラリはログライブラリにイベントハンドラを設定して、ログ発生時のイベントを受け取り、ログを文字コード変換し出力する。

そこまで考えたのはいいのだが、ログのイベントハンドラが1つしか設定できないと、ログ出力だけで占有する形になってしまう。

私の想定では、ログをファイルに出力しつつ、エラーログが発生した際には画面にアラートを出したりとか、そういうことをしたいのだ。そして、アラートを出すのはログ出力ライブラリの役割ではない。

とまぁそんな感じで、イベントハンドラは1つしか設定できないようにするべきではないなぁ、という結論に至ったわけだ。

なんかどんどん、JavaのAWTみたいな感じになっていく気がするが気のせいだろう。


2014/01/23 05:50

ログ出力のインターフェースはできた。

printf()で標準出力に出力するだけのしょうもない仮実装も作った。

ログを出力したら、それを別のところでイベントとして受け取り、イベントハンドラを呼び出す、とかもやりたいのだけれど、具体的にどういうインターフェースにするのかが定まっていない。

なのでその辺はまだできない感じかな。

とりあえずは、今までに作った箇所でログ出力が必要なところに記述を追加するとしよう。


2014/01/20 14:47

ビルド時に、バックエンドライブラリを指定できるように修正した。

というのをやってから、またやる気減退していたがまたがんばる。

設定ファイルのフォーマット定義、読み取り処理とか、C以外のプログラムの起動とか、その辺の対応をしたくはあるのだが、まだもやもやしていたために手を出せなかった。

それらを作るために、まずはロガーを作ることにした。

ロガーは、異常系にユーザが対応するための重要な要素になる。

異常系に対応するための要素と言えば、例えばステータスコードのリターンとか、例外のスローとかあるけど、今回の場合どちらも不適格だと思う。

基本的に、何か問題が発生したとして、自動的に何かをしなければならない、ということがないのだ。

ステータスコードを返したり、例外を送出したりというのは、プログラム内でどういう問題が発生したのか判別し、発生した問題への対処を自動的に行なうためのものだ。

逆に言えば、その場でプログラム内で問題に対処する必要がないのなら、成功ならtrue、失敗ならfalseで構わないと思う。

ただ、それだけでは発生した問題の種類も分からず、ユーザが対応することもできない。

そこでロガーというわけだ。問題が発生した時点で、それがどういう問題なのかをログとして出力する。

処理の結果としては、失敗しました、エラーログを参照してください、のようなものだけ表示する。

その時に、ログを参照すれば問題の原因を特定でき、対応が可能、という感じだ。

ログ出力はほぼ全てのライブラリが利用するはずなので、できるだけ早い段階で、インターフェースだけでも定義しておくべきだろう。他のライブラリのインターフェースにも影響するからだ。

そんな感じで、次はロガー対応。


2014/01/09 15:55

年末年始はのんびりしてたけど、数日前からちょびちょび再開している。

とりあえずは、インターフェースはそのままに、実装の気になるところを修正していた。

ダミー関数の定義自動生成もやっつけたし、他にも色々修正した。

今まで作ったところで修正するべきところはまだあると思うが、前のプロジェクトで作った機能についてもどんどん追加していきたいところ。

ひとまず、bitbucketの課題リストにつっこむところから始めるべきか。

新しいプロジェクトにしてから、まだ課題リスト使ってなかったしな。


戻る