デリゲート名ルール
GIJOE
調べても出てこなかったので、とりあえずここで質問します。
デリゲート名について、何か命名規則みたいなのってありましたっけ？
Wikiの XOOPSCube/CodingStyleGuide でもデリゲートには言及がありません。
XCLDB のP.231～232 にあるデリゲート一覧を見ても、特に規則らしいものは
見えてきません。
もしないなら、ある程度のルールを決めませんか？
すでにあるものについては動かせませんが、今後、各モジュールレベルで、
デリゲートを実装していく時に、せめてバッティングだけでも避けられるよ
うに。
モジュールレベルでデリゲートを呼び出すなら、
Module.(Dirname).(Action)
なんてのが良さそうです。でも、Dirname って、いくつかのモジュールでは
自由ですよね。となると、モジュールインスタンスではなくモジュールクラ
ス(?)で呼び出す状況も出てくるでしょうから、
ModuleClass.(TrustDirname).(Action)
なんかも押さえたいところです。
あと、現在のデリゲートを見ると、_と.を使い分けている見たいですけど、
何か意味がありますか？
（ここはたぶん、minahitoさん限定の質問）
のぶのぶ
正式なルールは公開されていませんが、かなり前に、旧xoopscube_dev MLにて
言及したスレッドがあった思うので、後で調べてみます。
> あと、現在のデリゲートを見ると、_と.を使い分けている見たいですけど、
> 何か意味がありますか？
> （ここはたぶん、minahitoさん限定の質問）
（限定に割り込みますが・・）
これは、XCubeの柔軟性提供手段として、開発開始当初はEventrを用意していたのがDelegateに
変更となったという経緯とも関連しますが、Delegate自体が現在大きく分けて2種類の使い方を
されているのに関係していると思います。（ネーミングと連動している保証はありませんが）
A.従来のX2時代のHack Pointに機能拡張を行う事を可能にするためのイベントのような物。
（フックポイントを表すイベント名をDelegateManagerで公開）
B.本来のDelegateの定義通りに、クラスのメソッドのDelegate化している場合
（クラスのメンバー変数をDelegate インスタンスにして、これに名前を付けてDelegateManagerで公開）
A.のケースの場合には、イベントの用途や利用シーン別で名前を付けている場合が多いと思います
（これが、名前のばらつきの一因になっていると思いますが）
B.のケースの場合には、原則的には、
ModuleClass.(Action)
を採用しているはずです。
回答になっておりますでしょうか？
---------
のぶのぶ
---------
GIJOE
> これは、XCubeの柔軟性提供手段として、開発開始当初はEventrを用意して
> いたのがDelegateに変更となったという経緯とも関連しますが、Delegate
> 自体が現在大きく分けて2種類の使い方をされているのに関係していると思
> います。（ネーミングと連動している保証はありませんが）
>
> A.従来のX2時代のHack Pointに機能拡張を行う事を可能にするためのイベ
> ントのような物。
> （フックポイントを表すイベント名をDelegateManagerで公開）
> B.本来のDelegateの定義通りに、クラスのメソッドのDelegate化している
> 場合（クラスのメンバー変数をDelegate インスタンスにして、これに名前
> を付けてDelegateManagerで公開）
ああ、その観点が抜けてました。なるほど、まったく違う使い方ですね。
汎用DBモジュールなんかでは、Bだけでロジック部を構成したら面白いかな、
なんて思いますが、既存のモジュールにフックポイントを追加するのなら、
ほとんどAですね。
のぶのぶ
>> A.従来のX2時代のHack Pointに機能拡張を行う事を可能にするためのイベ
>> ントのような物。
>> （フックポイントを表すイベント名をDelegateManagerで公開）
>> B.本来のDelegateの定義通りに、クラスのメソッドのDelegate化している
>> 場合（クラスのメンバー変数をDelegate インスタンスにして、これに名前
>> を付けてDelegateManagerで公開）
>
>> ああ、その観点が抜けてました。なるほど、まったく違う使い方ですね。
>
> 汎用DBモジュールなんかでは、Bだけでロジック部を構成したら面白いかな、
> なんて思いますが、既存のモジュールにフックポイントを追加するのなら、
> ほとんどAですね。
違う使い方ではあるのですが、Aはあとから拡張ポイントを作り込んでいく使い方
Bは、最初から拡張、換装可能に作り込んでおく使い方っていう面もあります。
たとえば、clase Sampleに mHogeというデリゲートインスタンスを定義し、
'Sample.Hoge'という名前で公開する場合に、標準動作は、クラス内の
プライベートメソッド_hoge を用意しておき、拡張する場合に、delegateで
オーバーライドなり、事前・事後処理の追加をさせるってな使わせ方を
あらかじめ用意しておくって事です。
Legacyのモジュール群では、この方式がかなり多用されています。
minahito
遅くなってすみません。
> 調べても出てこなかったので、とりあえずここで質問します。
> デリゲート名について、何か命名規則みたいなのってありましたっけ？
明示されているものは、特にないですが、途中から暗黙の命名規則が変わったこともあって、
Legacy だけ見てると分からない部分が多いと思います。;;
nobunobuさんが説明されたことを再度繰り返すことになりますが、
基本的には名称がぶつからなければどうでもいいのですが、
デリゲート（いわゆるコールバックポインタ）の公開にあたっては、
class ClassA
{
function B();
}
をデリゲート化する場合、
class ClassA
{
var $mB;
}
とします。
ここまではコーディングスタイルガイドで規定されてます。
で、これをデリゲートマネージャーに登録して公開する（static化する）場合は、
ClassA.B
と名付ける具合になっています。
ですので、
{クラス名} + {元のメソッド名}
が現状の（自分たちの中の）原則です。
> あと、現在のデリゲートを見ると、_と.を使い分けている見たいですけど、
> 何か意味がありますか？
> （ここはたぶん、minahitoさん限定の質問）
仮想的な名前空間として
{名前空間} _ {クラス名}
という名前を取ることになっているため、最終的に、
"Legacy" _ "FooHandler" . "Get"
みたいな登録名が導かれる感じになるんだと思います。
あくまでクラス名から入っているものであって、デリゲート名の中で独自に入れて、ピリオドと
使い分けているものではないです。
そのため、 PHP4 と PHP5 、
あと Legacy のような物理ベースで複製をとらないといけないものと、今後の BASE で積まれ
るシステムベースで複製を保証するものでは、名前空間、クラス名に関して独自のルールを敷い
ている現在の「暗黙のルール」とぶつかってしまう可能性があります。
そのため、ひとまず XOOPS Cube では命名規則を定めていません。
（やるなら、 BASE でやってね、というスタンスです。なので Legacy として規定していく必
要ありますね）
で、これだと複製モジュールでは色々都合が悪いと思いますので、
D3.TinyD.FooHandler.Get
のように
{ポリシー名} {固有名} {クラス名} {メソッド名}
などのコンベンションを作っていただいて構いません。
スペック的には、激突さえさけられればＯＫです。