パッチプラグインが作れるプラグインの構造を教えて下さい

[ムノクラ]

パッチプラグインが作れるプラグインの構造を教えて下さい。

1.基本的に即時関数化している箇所が同じであれば、同じ関数を上書きできるのでしょうか？
2.海外プラグインの多くに見られる、前置きの働きは何でしょう？
3.パッチプラグインを元プラグインを書き換えないと作れないプラグインにしない為には何に注意すべきでしょうか？
（以前に、そういうケースを見た記憶があるのですが、どこでだかは…）


以下は、自分の理解レベルを示すために書きます。

これまで少しですがMOGシリーズのパッチプラグインを作りました。
MOG、YEPシリーズは即時関数化されていないので、通常のプラグインを作る感覚で、関数を上書きする事で作ってきました。

SRD Summon Core のパッチプラグインを作成しました。
SRD Summon Core は即時関数化されていますし、コード内容が古そうですが、まっとうなコードっぽいのではと感じています。
（まだ、知識が追いついていないので、自分が当たりを付けられる程度には読みやすいという意味ですが…）
※直近のSRDシリーズのバージョンアップはGitHubに反映していないようです。
なぜかDropbox…
http://sumrndm.site/summon-core/

パッチプラグイン
https://github.com/munokura/RpgMakerMV/ ... chSkill.js

海外のプラグインで、マトモ（少なくとも即時関数化されている）に見えるプラグインの多くは、コードの最初に似た記述があります。

例：HIME_GameOverEvents.js
https://www.himeworks.com/files/rmmv/sc ... rEvents.js

コード: 全て選択

var Imported = Imported || {} ;
var TH = TH || {};
Imported.GameOverEvents = 1;
TH.GameOverEvents = TH.GameOverEvents || {};

GalvやVEシリーズにも似た記述があります。
これがパッチプラグインを作る準備かと考えたのですが、他の事例を見るとそういうわけでもないようです。

例：
▼全体攻撃スキルで全員同時にダメージ（Trb様作）
https://plugin.fungamemake.com/archives/19566

▼PromptlyPopup.js が有効な場合、連続攻撃や全体攻撃のダメージ/回避SEの再生をそれぞれ1回に抑えます。
https://github.com/elleonard/RPGtkoolMV ... amageSe.js

[奏ねこま]

■方法１：関数（クラス）定義部を即時関数の外に出す

コード: 全て選択

function Window_XXX() {
    this.initialize.apply(this, arguments);
}

(function(){
    :

    Window_XXX.prototype.initialize = function() {
        :
    };

    :
}());

■方法２：関数（クラス）をグローバルにコピーする

コード: 全て選択

(function(){
    :

    function Window_XXX() {
        this.initialize.apply(this, arguments);
    }

    window.Window_XXX = Window_XXX;

    :
}());

■方法３：グローバルに用意した変数に関数（クラス）をコピーする

コード: 全て選択

var MyClasses = {};

(function(){
    :

    function Window_XXX() {
        this.initialize.apply(this, arguments);
    }

    MyClasses.Window_XXX = Window_XXX;

    :
}());

[Plasma Dark]

海外のプラグインで、マトモ（少なくとも即時関数化されている）に見えるプラグインの多くは、コードの最初に似た記述があります。

YEPにも似た記述があったように記憶しています。
これは単に名前空間を定義し、コアや他のプラグインとクラス名、関数名、変数名を衝突させないための工夫です。

コード: 全て選択

var Imported = Imported || {} ;
var TH = TH || {};
Imported.GameOverEvents = 1;
TH.GameOverEvents = TH.GameOverEvents || {};

この中で Imported は、特定のプラグインが読み込まれているかどうかを表す集合として暗黙的に使われているようです。
つまり、他のプラグインから if (Imported.GameOverEvents) { ... } などと記述することで、そのプラグインが読み込まれていた場合の特別な処理が書けます。

TH は何の略かちょっとわかりませんが、これで名前空間を宣言しています。
TH.GameOverEvents なるオブジェクトを定義し、即時関数の中でそのオブジェクトに変数を追加しています。

この TH や TH.GameOverEvents という名前空間はグローバルな領域に置かれた変数ですので、他のプラグインからも参照や更新が可能です。

[Plasma Dark]

3.パッチプラグインを元プラグインを書き換えないと作れないプラグインにしない為には何に注意すべきでしょうか？

クラスを定義する場合、定義をグローバルから参照できないようにすると、そのクラスの挙動は外から書き換えられなくなります。
ただ、パッチが有効な作りにすることを意識するよりは、githubでマスターとなるプラグインを公開し、他の開発者からのコミットを受け入れやすくしておくことを意識するほうが健全だと私は考えます。

パッチを作らなければならない状況というのはつまり、マスターとなるプラグインがまともにバージョン管理、メンテナンスされておらず、対症療法でバグ修正や機能拡張を行わなければならないか、元の仕様をごく限られた（一般化しにくい）用途向けに拡張、改変したいケースに限定されます。

少なくとも前者については、githubでマスターが公開されているようなプラグインであれば修正PRを出してメンテナに連絡して取り込んでもらうことができます。（メンテナが活動していない場合は、誰かが引き継ぐ必要はありますが、githubであればForkで容易にリポジトリごと引き取ることが可能です）

後者の場合を考えてそのための口を用意してあげることを考えても良いですが、要望があってからの対応でも遅くはないと思います。

[ムノクラ]

お二人とも、素早く的確なご指導をいただき、ありがとうございます。

今の自分で直ぐに理解できるのは、下記のようです。

(奏ねこま様)
1.■方法１：関数（クラス）定義部を即時関数の外に出す
　　　2.も何とか分かるような気がする
　　　3.はどう扱えば良いのか？？？
　…というレベルです。

(Plasma Dark様)
2.この中で Imported は、特定のプラグインが読み込まれているかどうかを表す集合として暗黙的に使われているようです。
つまり、他のプラグインから if (Imported.GameOverEvents) { ... } などと記述することで、そのプラグインが読み込まれていた場合の特別な処理が書けます。
　　　これは、コアの同じ関数を扱うプラグインの競合対策に使えそうだと理解できます。
　　　（合ってますか？）

(Plasma Dark様)
3.窓口としてGitHubを使うべし！ということですよね？
SRDシリーズのように利用規約がアレ（再配布禁止、利用の改変にファイル名の変更も禁止）だと、連絡が取れないとForkできないとは思います。
GitHubの機能としてあるので、その辺りのGitHubの理念が、よく分からないという印象です。
ただ、GitHubで公開することで、修正PR等出しやすいというのは（知識としては）理解できます。
（PRの出し方も、受け入れ方も理解できていないので…）

あとは、そんな余計なことは現時点で気にしないで、GitHubで公開しておけば、後から考えても間に合う！ってところでしょうか。

もう少し、頂いた情報から実験して学習を進めようと思います。

他の方も何かお気づきの点があれば、ご指導ください。
この通り、既存プラグインの機能とコードとコアスクリプトを見比べて、皆さんの助言を受けてプラグインを書いているレベルですので、アドバイスできる範囲が少なすぎるかも知れませんが、今後ともご指導いただきたく、お願いいたします。