@sumiyaki @vaginaplant 別の観点から言うと、開発側が安定したコードを維持するより、いつでもリファクタリングしたり機能変更できる状態を維持していたい、という部分はあると思います。
Pleromaにしろ、Misskeyにしろ、破壊的変更に躊躇がありません。APIすら安定していない状況で、プラグインどころではないと思います。
また、Railsなどのフレームワークは、それ自体が機能追加・変更の仕方を規定していて、直接いじることを前提にしているところがあり、プラグイン実装にあまり向いていないのではないかと思います。
@sumiyaki @vaginaplant PythonのYapsyはイメージしているプラグインにあたると思いますが、Behaviorやgemはソースコードを書き足すイカした方法という感じかな。
プラグインをAPIのように簡単に記述できるようにするには、ソースコードのあちこちにフックを用意するか、機能をもっと分類整理してアプリケーションをプラグインの集合体のように構成することで、追加や差し替えを容易にする、という感じになるかと思います。
個々のプラグインは呼び出されただけではデータや機能にアクセスできないので、データや機能を抽象化してAPI通じて提供しなきゃいけないし、
変更したい部分が切り出されていないと手が出せないし、
諸々、あらかじめ設計に含んでおかなければならないので、結局、プラグインで何をしたいかが問われますね。
いずれにしても、整備して維持するために、かなりのマンパワーが要るんじゃないかなぁ。
言語やフレームワークの便利機能を使わず、自力で再実装するような作りになりがちなのであります。
ありがとうございます。
確かに、プラグイン機構を構成しながら開発を進めるとなると、かえって負担が大きくなったり、柔軟な開発ができなくなるなど、は想像できます。
ただ、Firefoxのプラグインにしても、けっこうちゃぶ台返しされているから、仕様は永遠の保証みたいには考えなくても、とりあえず固まって来た、くらいでもよいのでは、という気もします。
本当は、gitでコンフリクトが起きてもうまくマージしてくれる人工知能みたいなものができれば一番よいのでしょうけど。
とりあえず、言語とpluginでぐぐってみると、
ElixirではBehavior
PythonではYapsy
RoRでは
https://railsguides.jp/plugins.html
なんていうものが見つかりました。