Closure Compilerでのクラスの書き方 @lendsは止めよう編

June 18, 2014

クラスを書くときの様式を変更したので覚書。

以前ポストした記事で @lends使った書き方でいーかなーと思ってたんですが、

結構 @lendsを使った書き方だとWARNING LEVELをVERBOSEにした場合に「クラスが見つからない」だのなんだのと文句を言われる事になる事がわかった。

不具合として報告しようにも、最小のソースをコンパイルしても同じ警告は発生せず、気が付いたら警告が出ない場合もあるなどどうにもこうにも対策のしようが無い印象(^^;

諦めてクラスを書く場合は以下の様式に統一するようにした。

    /* 出来るだけ即時関数でWrapする事はしない */
    /* Class local な static文字列とか使いにくいけど */

    /**
     * @classdesc
     * クラスの詳細
     * @extends {Base} ベースクラス
     * @implements {Interface} インターフェース
     *
     * @constructor
     * @param {Object=} o
     */
    function Clazz(o) {
        // ベースクラスのコンストラクタ呼び出し
        Base.call(this, o);
        // プロパティの初期化
        /**
         * @type {number}
         */
        this.prop1 = 0;
    }

    /**
     * 説明文章
     *
     * @summary メソッドのサマリを書く
     * @this {Clazz} @this宣言は書く(thisもパラメータの一つと考える)
     * @param {number=} p パラメータはthisの後に続ける
     * @returns {number|undefined} null的な意味で値を戻す場合、nullよりもundefinedを返すで登録したほうが都合が良い事が多い。== nullの比較は undefinedもtrueなので問題無い。
     */
    Clazz.prototype.methodA = function (p) {
        // 継承した関数の呼び出し。
        Base.prototype.methodA(this, p);
    };

なんつーか。特に継承したベースクラス関連の呼び出し。無名関数でwrapしてBase.prototypeとかを

bindされた変数に格納しておけばもう少しシンプルにかけるってのは分かっちゃいるんだけど、

Closure CompilerでADVANCED_OPTIMIZATIONSを使いたい場合はできるだけシンプルに書いた方が

発生事由の良くわからない警告に悩まされる可能性は低い様に思う。

警告を無視するというのもありかなーとは思うのですが、、、。