2018-05-07

ライブラリの依存性

Scheme でライブラリを書いていると巨大なファイルになることがままある。最近だとこのファイル。まだ未完成なのだが既に1000行近くある(まだ1000行とも言えるが、個人的にファイル内の移動が既に辛い)。辛いなら分ければいいじゃない?という話なのだが、怠け者根性と分け方で迷っているというのの2つがあって今のところ放置している。

ライブラリを複数のサブライブラリに分ける際に大抵以下の2種類のパターンで迷う:
  1. 機能ごとに分ける(例:型、手続き、etc.)
  2. オブジェクト指向的に分ける
個人的にどちらが優れているという気はないし、ケースバイケース(その時の気分ともいう)で違う分け方をしている。今回は2の方向で分けたいと思っているのだが、これだと不都合がでる。ライブラリの循環だ。

今作っているライブラリはXMLのDOMを扱うものなのだが(最終的にどこまでサポートするかは不明)、DOMにはquerySelectorなる手続きがある。これはParentNodeで定義されているが、このインターフェースはDocumentDocumentFragment及びElementで実装されている。CLOSを使っていないので、これらは別々に実装される必要があって、どう実装するかは考えてないんだけど、3つの似たりよったりな手続きが実装されることになると思われる。そうすると、この手続きはどこか別の場所に分けたいのだが、ライブラリをオブジェクト指向的に分けるとこんな感じになって、循環する:
  • Elementライブラリ: Selectorライブラリが必要
  • Documentライブラリ: Selectorライブラリが必要
  • DocumentFragmentライブラリ: Selectorライブラリが必要
  • Selectorライブラリ: Elementライブラリが最低必要
 (Selectorライブラリに分けたいのはこいつが別仕様だからだったりする。)

こういう時は機能毎に分ければうまく行くんだけど、なんだかなぁという気がしていて、う〜ん。ライブラリの遅延ロードみたいなのを導入して循環参照を許してもいいんだけど、それもなぁ的な。Schemeのライブラリは生まれて日が浅い(と言っても既に数年経っているが)ので、こういう場合のベストプラクティス的なものはないし(Scheme的にはこういうケースでベストプラクティスが必要なのって言語仕様的にどうよってなる気もしないでもないがどうなの?)、さてどうしようかね…

No comments:

Post a Comment