Hawk
w3l_admin****@hawk*****
2006年 6月 27日 (火) 22:28:25 JST
Hawkです。
何となくdev-MLの方が相応しい内容の気もしますが、お答えしておきます。
> Perlの方式(perl付属/vender_perl/site_perlとディレクトリを用意する)は検討
> されましたでしょうか。
> 検討されいるとすれば、同方式では何かネックがあるのでしょうか？
例えばMaple本体付属、共有ライブラリ、アプリケーション固有というように、
いくつかの階層を持たせる方法は検討しましたし、
開発者間での議論においても提案したはずです。
その時どんな議論になったのかは記憶にも記録にもないので分かりませんが
（恐らくあまり身のある内容にならなかったのでしょう……）
私が個人的にネックだと感じた（ている）のは、
Mapleの場合、むやみに自由度が高いために、
何をどう階層化すべきなのか判断が付けにくいという点です。
少なくとも、ただ単にディレクトリを分けるだけでは
なかなかうまくいきそうにありません。
例えばConverter_*というファイル群がありますが、
これらの命名規則・インターフェイス等は厳密に言えばMaple本体ではなく、
Filter_Convertという一フィルタの管轄であり、フィルタさえ交換すれば
どうとでもなります（拙作のConvert2フィルタ然り）。
さらにこのFilter_*というファイル群もまた
FilterChainという一コンポーネントが管理しており、
変更可能な部分です。
そうやって突き詰めていくと、狭義のMaple本体は非常に薄いものとなり、
階層化する意味のある部分は、軒並み拡張機能の管轄となってしまいます。
「本体付属」の「本体」が、
「Maple本体」ではなく「『Mapleの拡張機能』本体」を
意味するようになってしまうのですね。
だから「Maple本体」としては、拡張機能も、拡張機能の拡張機能も
包括的統一的に扱えるような仕組みを用意してやって、
拡張機能の側も、勝手気ままに独自の管理体制を敷くのではなく、
本体側の仕組みを利用するようにする……という風に再構成する必要があるので
しょう。
”Perlの方式”がそこまでを意味するなら、確かにそれは検討すべき
目指すべき方式であり、今の段階では単に未到達である、
ということになります。
……
かなり長くなりましたが、
> (すいません、こういった話は好きなもので...)
とのことなので、書けるだけ書いておきました。
今回の件で私も刺激を受けましたので、また色々考えてみます。
とりあえず、現在のMapleは自分の好きなように改造し尽くすのが
一番の活用法であることは間違いないでしょう。
カスタムベースにどうぞ。
--
Hawk : {
web site : http://blog.hawklab.jp/
}