Re: [ruby-gnome2-devel-ja] 命名規則などの提案

[Masaaki A. <mas...@gm...>]

青柳です。

>> 自動化しやすくすることや冗長性を排除していくことを目的に、以下の規則を提案します。
>
> 目的は理解できます。
> が、少しやり過ぎかなぁという気がしました。

やっぱり、そう思われますか。


> うーん、でも、ドキュメント化されていれば杞憂になるのかなぁと
> いう気もします。今はここに書いてありますが、これから書くなら
> Hikiじゃないところの方がいいですよねぇ。
>  http://ruby-gnome2.sourceforge.jp/#For+Developers
>  http://ruby-gnome2.sourceforge.jp/hiki.cgi?How+to+Implement+Ruby-GNOME2

yardドキュメントを埋め込む方向で今やっているので、ソースに書くのがいいのでしょうか？


>>  * 1ファイル＝1名前空間（クラスまたはモジュール）とする
>
> よいと思います。
>
>>  * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ
>>　 例）Vte::Terminal → rbvte-terminal.c
>
> よいと思います。
>
>>  * 名前空間の変数名（TARGET_NAMESPACE）は、m<モジュール名> とする
>>　 （クラスの場合は、c<クラス名>）
>>　 例）Vte::Terminal → cTerminal
>
> TARGET_NAMESPACEは↓のマクロとかでいろいろ暗黙的に使われるの
> で、やり過ぎかもなぁという気がしました。
> （でも、ドキュメント化で解決するかもとは思っています。）

TARGET_NAMESPACEを隠蔽しようとしているのは、1ファイル＝1名前空間を強制させる意味が大きく
ちょっとやりすぎ感は確かにあるのですが、この方式にしたいです。


> あと、名前が一般的なのでprefixをつけた方がいい気がしました。
> 個人的にはprefixは「RBG_」に統一したいなぁと思っていましたが、
> 「RG_」でもいいと思います。
>
> 変数名ですが、staticなやつはm<モジュール名>やc<クラス名>でよ
> いと思います。ただ、staticじゃないやつはprefixをつけた方がい
> いと思っています。今は、mGLibとかそのまま出ちゃっていますが、
> rbg_mGLibとかrg_mGLibにした方がいいと思っています。

確かに、そうですね。


>>  * rubyからのIFになっている関数名は、rg_<メソッド名> とする
>>　 （シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>）
>
> いいと思います。
>
>>　 使用マクロ：G_DEF_METHOD、G_DEF_SMETHOD、G_DEF_MODFUNC
>
> 既存のマクロがG_DEF_はじまりなので揃えてくれたんですよね。
> でも、これをチャンスにG_ではないprefixにしてもいいかなぁと思っ
> ています。G_はGLibでも使っているので、同じのは使わないほうが
> いいかなぁと思っています。
>
> ↓のマクロ名も同じように思っています。
>
>>  * ? 付きメソッドの関数名は、末尾に ? の代わりに _q を付ける
>>　 使用マクロ：G_DEF_METHOD_Q、G_DEF_SMETHOD_Q、G_DEF_MODFUNC_Q
>
> qはquestionの略ですよね。
> LispとかRuby本体ではpredicateな関数・メソッド（述語。真偽値
> を返す関数・メソッド）に?をつけるので、_qではなく_pの方がい
> いかなぁと思いました。

predicateと言うのですか。
では、_pでいいですかね。


>>  * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける
>>　 使用マクロ：G_DEF_METHOD_E
>
> eはexclamationの略ですよね。
> Ruby本体ではbangを使っているのでそっちにあわせる方がいいかなぁ
> と思いましたが、_bだとなんだかわからないんですよねぇ。_bang
> でもいい気がしますが、1文字がいいんですよね。うーん。

! 付きメソッドは、それほど多くないはずなので、_bangでいいですかね。


>>  * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする
>>　 使用マクロ：G_DEF_METHOD_OPERATOR、G_DEF_SMETHOD_OPERATOR、G_DEF_MODFUNC_OPERATOR
>
> いいと思います。
>
>> 上記規則を適用した vte の変更したソース自体と差分を添付しますので、ご確認ください。
>> 現時点では、マクロを rbvte.h に定義していますが、全体に適用できることになったら glib2 に移動したいと考えています。
>> なお、コミットする際はいくつかの段階に分けて行う予定です。
>
> 個人的にはprefix関連は必ず解決したいことで、それ以外は青柳さ
> んの意見を尊重する方向でいいかなぁと思っています。

ありがとうございます！
すみません、今調べたらrg_もrgb_も使っている箇所がありましたが、どうしましょう？
マクロのprefixも新たにしてマクロの整理も行う方向に持っていけたらベストでしょうか。


> やり過ぎ感をもう少し書いておくと、一回リポジトリからremoveす
> る前のRuby/GIO2みたいな方向になっていくのを危惧しています。
> ソースコードを見てもらえばわかると思うのですが、「たしかに
> Rubyの拡張ライブラリを作っているCなんだけど、違う言語に見え
> る」、という感じになっています。
>
> r3724で削除したので、これで見れると思います。
>  http://ruby-gnome2.svn.sourceforge.net/viewvc/ruby-gnome2/ruby-gnome2/trunk/gio/?pathrev=3723

なるほど、似たようなことをやってらっしゃいますね。。。
ただ、自分が考えているのは実装やドキュメントの不足チェックとテンプレート生成を自動化することが主な目的なので、
関数定義の部分まで手を突っ込むことはないと思います。