SC_* のコンストラクタの拡張が無視される

[Seasoft]

課題

• 拡張ページクラスで親クラスのコンストラクタをコールするように改訂すると、(EC-CUBE の標準実装の開発として) コンストラクタの引数を変更する場合に2つのクラスの同期を保証する必要があり、メンテナンスコストが上がる。
  • PHP の場合、「関数処理」関数で回避する方法も考えられそう。しかし、この場合実行コストがどの程度上がるか把握していない。また、ソースの連続性がなくなり、ソース分析が面倒になる (多分、ツール類では構造分析できない)。
• PHP の言語仕様 (コンストラクタは継承しない) との整合は無視するのか?

[Seasoft]

親クラスのコンストラクタを呼び出す実装をプロトタイピングしましたが、EC-CUBE 本体の開発に対する保守性が悪くなりそうなので破棄します。

カスタマイズの際は、拡張クラスを使用せずに親クラスを書き換えるのが妥当なんですかね。

[shutta]

個人的には、拡張クラスがある以上は、現状ではカスタマイズは拡張クラスを使用するのを想定するのが本来だと思っています。

そのため、2.11の際に、ひと通りclass_extendsに対応させましたが、 SC_View周りを r20306 で、拡張クラス対応した際にコンストラクタ部分まで考慮できていませんでした。

本チケットは、閉じられてしまってますが、構造に関して再度議論できればと思い、復活させて頂きます。

[Seasoft]

個人的には、拡張クラスを次バージョンあたりで削除するのが理想と考えているので破棄したのですが、2.11 系としての対応としては、本来はバグとして修正するのが正しいと思います。

そのため、2.11の際に、ひと通りclass_extendsに対応させましたが、 SC_View周りを r20306 で、拡張クラス対応した際にコンストラクタ部分まで考慮できていませんでした。

SC_View に限らず、SC_* と SC_Helper_* 全般での対応が必要になると思います。

参考までに、私が検討した際の課題を説明欄に記載しておきますね。