プラグインのあるべき姿を考えてみる - その2

プラグインの仕組みを少し考えてみます。

フックポイントにPluginの処理を差し込んで、フレームワーク側の処理に手を加えるものは、いわゆる世間一般にプラグインと言われているものなんじゃないかと思います。これはMooseのRoleのmethod modifireは相性はよさそうです。フックポイントに対して差し込む処理と差し込む処理を実行するタイミングをコントロールできるからです。

ただ、MooseのRoleのmethod modifireのパターンは、Class::Triggerのようにフックポイントが明示されているわけではないので、プラグインとして提供する場合にはフックポイントを明示する仕組みを用意したほうがいいのかもしれないなぁとは思いました。

Catalystのリクエストライフサイクルに処理を挟み込むのは、この形があっているのではないかと思います。多分、これがエンジンのプラグインとして提供されるべき機能です。

では、一般的なプラグインの定義からは外れるけれども、フレームワークに機能を追加したいというものはどうするのがよいでしょうか。例えば、Controllerなどに機能を追加したい場合です。これは、Controllerとしてリリースするのがいいでしょうか。ここには、もう少し検討の余地があるように思います。

現状の場合で、Controllerとしてリリースした場合に、複数のCapabilityを満たすControllerのベースクラスを作りたい場合がどうなるかを考えてみます。この場合、いくつかの汎用Controllerを多重継承することになります。これだとグローバルに機能共有するわけではないので、バッティングする可能性そのものは減りますが、メソッドのバッティングは防げなそうです。これだけでは、あまり良い解とはいえなそうです。

MooseのRoleはこれに対して一つの解があります。MooseのRoleをconsumeするタイミングで、違うメソッド名をつけられるからです。これによって複数の機能拡張をマージする事で運悪くバッティングしてしまったとしても、バッティングすることを回避して機能をMixinすることができます。

単一継承+Mixinは、多重継承による複雑なクラス構成をさけるのに役立ち、さらにRoleのようにaliasを用意する事で、いわゆるCatalystでいうComponentレベルでの昨日共有を促進できる可能性があるような気がします。

要するに、Mixinベースにして、さらにMooseのRoleのようにconflictした場合の回避策（別名へのalias)を用意するという形で、機能拡張をしていける仕組みを提供するというのが一つあるんじゃないかと思いました。

もっと明示的にフレームワークとして拡張ポイントを用意するというのもあるとは思うんですが、ここら辺はどういうものがプラグインになるべき仕組みとして用意できるのかがわからないので、あれだなと。

このようなことを夢想してみました。PerlでのPluginシステムやフレームワークの拡張方式にはまだまだ先がありそうなので、何がよくて、何が悪いかを考えていきたいなと思っています。