>>43
internal_class_nameの件は、よくあるプラグインの仕組みみたいですね
レコードのinsert/deleteに対応して、カラムが示すクラスを動的にロード／アンロードする感じですよね

意見ですが、プラグインのエントリーポイントとなるクラスのベースタイプは各拡張対象そのものではなく
PlugInとかにして、そのクラスがサブクラスに実装を要求する関数の中で
add_trigger_channel/add_action_channelとかして各拡張を登録する仕組みにすれば
- プラグインローダー部分はシンプルになる（今後拡張対象が増えてもローダーの修正は不要）
- 単一のパッケージとして複数の拡張を提供できる（Slackに関するトリガー／アクションのセット、みたいな）
というメリットがあるかなーと思いました