|
From: Masaaki A. <mas...@gm...> - 2011-07-23 10:38:04
Attachments:
rules.zip
rules.diff.gz
|
青柳です。 自動化しやすくすることや冗長性を排除していくことを目的に、以下の規則を提案します。 * 1ファイル=1名前空間(クラスまたはモジュール)とする * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ 例)Vte::Terminal → rbvte-terminal.c * 名前空間の変数名(TARGET_NAMESPACE)は、m<モジュール名> とする (クラスの場合は、c<クラス名>) 例)Vte::Terminal → cTerminal * rubyからのIFになっている関数名は、rg_<メソッド名> とする (シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>) 使用マクロ:G_DEF_METHOD、G_DEF_SMETHOD、G_DEF_MODFUNC * ? 付きメソッドの関数名は、末尾に ? の代わりに _q を付ける 使用マクロ:G_DEF_METHOD_Q、G_DEF_SMETHOD_Q、G_DEF_MODFUNC_Q * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける 使用マクロ:G_DEF_METHOD_E * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする 使用マクロ:G_DEF_METHOD_OPERATOR、G_DEF_SMETHOD_OPERATOR、G_DEF_MODFUNC_OPERATOR 上記規則を適用した vte の変更したソース自体と差分を添付しますので、ご確認ください。 現時点では、マクロを rbvte.h に定義していますが、全体に適用できることになったら glib2 に移動したいと考えています。 なお、コミットする際はいくつかの段階に分けて行う予定です。 |
|
From: Kouhei S. <ko...@co...> - 2011-07-23 12:10:41
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] 命名規則などの提案" on Sat, 23 Jul 2011 19:37:58 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 自動化しやすくすることや冗長性を排除していくことを目的に、以下の規則を提案します。 目的は理解できます。 が、少しやり過ぎかなぁという気がしました。 うーん、でも、ドキュメント化されていれば杞憂になるのかなぁと いう気もします。今はここに書いてありますが、これから書くなら Hikiじゃないところの方がいいですよねぇ。 http://ruby-gnome2.sourceforge.jp/#For+Developers http://ruby-gnome2.sourceforge.jp/hiki.cgi?How+to+Implement+Ruby-GNOME2 > * 1ファイル=1名前空間(クラスまたはモジュール)とする よいと思います。 > * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ > 例)Vte::Terminal → rbvte-terminal.c よいと思います。 > * 名前空間の変数名(TARGET_NAMESPACE)は、m<モジュール名> とする > (クラスの場合は、c<クラス名>) > 例)Vte::Terminal → cTerminal TARGET_NAMESPACEは↓のマクロとかでいろいろ暗黙的に使われるの で、やり過ぎかもなぁという気がしました。 (でも、ドキュメント化で解決するかもとは思っています。) あと、名前が一般的なので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の方がい いかなぁと思いました。 > * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける > 使用マクロ:G_DEF_METHOD_E eはexclamationの略ですよね。 Ruby本体ではbangを使っているのでそっちにあわせる方がいいかなぁ と思いましたが、_bだとなんだかわからないんですよねぇ。_bang でもいい気がしますが、1文字がいいんですよね。うーん。 > * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする > 使用マクロ:G_DEF_METHOD_OPERATOR、G_DEF_SMETHOD_OPERATOR、G_DEF_MODFUNC_OPERATOR いいと思います。 > 上記規則を適用した vte の変更したソース自体と差分を添付しますので、ご確認ください。 > 現時点では、マクロを rbvte.h に定義していますが、全体に適用できることになったら glib2 に移動したいと考えています。 > なお、コミットする際はいくつかの段階に分けて行う予定です。 個人的にはprefix関連は必ず解決したいことで、それ以外は青柳さ んの意見を尊重する方向でいいかなぁと思っています。 やり過ぎ感をもう少し書いておくと、一回リポジトリからremoveす る前のRuby/GIO2みたいな方向になっていくのを危惧しています。 ソースコードを見てもらえばわかると思うのですが、「たしかに Rubyの拡張ライブラリを作っているCなんだけど、違う言語に見え る」、という感じになっています。 r3724で削除したので、これで見れると思います。 http://ruby-gnome2.svn.sourceforge.net/viewvc/ruby-gnome2/ruby-gnome2/trunk/gio/?pathrev=3723 |
|
From: Masaaki A. <mas...@gm...> - 2011-07-23 15:11:26
|
青柳です。 >> 自動化しやすくすることや冗長性を排除していくことを目的に、以下の規則を提案します。 > > 目的は理解できます。 > が、少しやり過ぎかなぁという気がしました。 やっぱり、そう思われますか。 > うーん、でも、ドキュメント化されていれば杞憂になるのかなぁと > いう気もします。今はここに書いてありますが、これから書くなら > 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 なるほど、似たようなことをやってらっしゃいますね。。。 ただ、自分が考えているのは実装やドキュメントの不足チェックとテンプレート生成を自動化することが主な目的なので、 関数定義の部分まで手を突っ込むことはないと思います。 |
|
From: Masaaki A. <mas...@gm...> - 2011-07-23 16:30:18
|
青柳です。 >> すみません、今調べたらrg_もrgb_も使っている箇所がありましたが、どうしましょう? >> マクロのprefixも新たにしてマクロの整理も行う方向に持っていけたらベストでしょうか。 > > そうですね。 > ざっと見てみたら、rg_よりもrbg_の方が多いので、rbg_に統一す > る方向でいきましょう 説明不足でしたが、「あるprefixを持った関数=rubyからのIF」と言えるようにしたいと思っています。 rbg_を使うとすると、例えば rbg_cstr2rval のようなIFになっていない関数は名前を変えたいですが グローバルスコープですし、それは難しいですよね? rb_の方は、関数として使われているのは static の rg_poll のあたりなので名前の変更は出来るでしょうか。 他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか? |
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 07:33:39
|
青柳です。 >> 他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか? > > 例えば、どんなのがよさそうでしょうか? 単純に、rbif_ または rif_ というのは、いかがでしょうか? いずれも使われていませんでした。 マクロの方のprefixは、使われていますが RBG_ でよろしいでしょうか? |
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 09:17:26
|
青柳です。 > 関数の方もマクロの方もprefixは揃えた方がよいと思うので、 > rg_/RG_でいかがでしょうか!? では、rg_poll のあたりの関数はいずれ変更するということで。 マクロの方は、RG_DEF_CONVERSION というのだけありますが、そのままでもいいでしょうか? 今までの内容をまとめると、 * 1ファイル=1名前空間(クラスまたはモジュール)とする * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ 例)Vte::Terminal → rbvte-terminal.c * 名前空間の変数名(RG_TARGET_NAMESPACE)は、m<モジュール名> または c<クラス名> とする (グローバルスコープの場合は、prefixとして rg_ を付ける) 例)Vte::Terminal → cTerminal * rubyからのIFになっている関数名は、rg_<メソッド名> とする (シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>) 使用マクロ:RG_DEF_METHOD、RG_DEF_SMETHOD、RG_DEF_MODFUNC * ? 付きメソッドの関数名は、末尾に ? の代わりに _p を付ける 使用マクロ:RG_DEF_METHOD_P、RG_DEF_SMETHOD_P、RG_DEF_MODFUNC_P * ! 付きメソッドの関数名は、末尾に ! の代わりに _bang を付ける 使用マクロ:RG_DEF_METHOD_BANG * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする 使用マクロ:RG_DEF_METHOD_OPERATOR、RG_DEF_SMETHOD_OPERATOR、RG_DEF_MODFUNC_OPERATOR こんな感じで、よろしいでしょうか? |
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 10:15:25
Attachments:
divide_by_namespace.diff.gz
|
青柳です。 まず、名前空間毎にファイルを分離するパッチです。 cTerminalEraseBinding のような変数は不要だったので削除もしています。 よろしければ、コミットいたします。 |
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 12:26:33
Attachments:
naming_rules.diff.gz
|
青柳です。 最後に命名規則を適用するパッチです。 ご確認をお願いします。 |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 12:46:38
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 21:26:27 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 最後に命名規則を適用するパッチです。 > ご確認をお願いします。 これもお願いします! |
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 12:59:26
|
青柳です。 コミット完了しました。 ご確認、ありがとうございました! |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 11:56:15
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 19:15:19 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > まず、名前空間毎にファイルを分離するパッチです。 > cTerminalEraseBinding のような変数は不要だったので削除もしています。 > よろしければ、コミットいたします。 お願いします!!! |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 09:22:37
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 18:17:19 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >> 関数の方もマクロの方もprefixは揃えた方がよいと思うので、 >> rg_/RG_でいかがでしょうか!? > > では、rg_poll のあたりの関数はいずれ変更するということで。 そうですね。 > マクロの方は、RG_DEF_CONVERSION というのだけありますが、そのままでもいいでしょうか? はい。今回の変更の方針とぶつかるものではないと思うので、その ままでよいと思います! > 今までの内容をまとめると、 > > * 1ファイル=1名前空間(クラスまたはモジュール)とする > * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ > 例)Vte::Terminal → rbvte-terminal.c > * 名前空間の変数名(RG_TARGET_NAMESPACE)は、m<モジュール名> または c<クラス名> とする > (グローバルスコープの場合は、prefixとして rg_ を付ける) > 例)Vte::Terminal → cTerminal > * rubyからのIFになっている関数名は、rg_<メソッド名> とする > (シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>) > 使用マクロ:RG_DEF_METHOD、RG_DEF_SMETHOD、RG_DEF_MODFUNC > * ? 付きメソッドの関数名は、末尾に ? の代わりに _p を付ける > 使用マクロ:RG_DEF_METHOD_P、RG_DEF_SMETHOD_P、RG_DEF_MODFUNC_P > * ! 付きメソッドの関数名は、末尾に ! の代わりに _bang を付ける > 使用マクロ:RG_DEF_METHOD_BANG > * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする > 使用マクロ:RG_DEF_METHOD_OPERATOR、RG_DEF_SMETHOD_OPERATOR、RG_DEF_MODFUNC_OPERATOR > > こんな感じで、よろしいでしょうか? よいと思います! |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 08:01:09
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 16:33:33 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >>> 他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか? >> >> 例えば、どんなのがよさそうでしょうか? > > 単純に、rbif_ または rif_ というのは、いかがでしょうか? > いずれも使われていませんでした。 ifですか。。。 他では見たことがない字面なのが気になりました。 うーん、そうですねぇ。 とすると、現在あまり使われていないrg_を使うのがよい気がして きました。 > マクロの方のprefixは、使われていますが RBG_ でよろしいでしょうか? ↑もせっかくなのでキレイなところからスタートしたいですよね? RG_なら1から決めていけるのでそっちの方がやりやすい気がします。 関数の方もマクロの方もprefixは揃えた方がよいと思うので、 rg_/RG_でいかがでしょうか!? |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 03:11:08
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 01:30:12 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 説明不足でしたが、「あるprefixを持った関数=rubyからのIF」と言えるようにしたいと思っています。 なるほど。 > rbg_を使うとすると、例えば rbg_cstr2rval のようなIFになっていない関数は名前を変えたいですが > グローバルスコープですし、それは難しいですよね? そうですね。 やるなら、まずは、rbg_cstr2rval()を使ったらrb_warn()で警告が でるようにして、しばらくしたら削除、という感じだと思います。 > rb_の方は、関数として使われているのは static の rg_poll のあたりなので名前の変更は出来るでしょうか。 こっちはすぐにできますね。 > 他のprefixを考えた方がいいのかなと思ったのですけど、いかがでしょうか? 例えば、どんなのがよさそうでしょうか? |
|
From: Kouhei S. <ko...@co...> - 2011-07-23 15:29:42
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 00:11:19 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >> うーん、でも、ドキュメント化されていれば杞憂になるのかなぁと >> いう気もします。今はここに書いてありますが、これから書くなら >> Hikiじゃないところの方がいいですよねぇ。 >> http://ruby-gnome2.sourceforge.jp/#For+Developers >> http://ruby-gnome2.sourceforge.jp/hiki.cgi?How+to+Implement+Ruby-GNOME2 > > yardドキュメントを埋め込む方向で今やっているので、ソースに書くのがいいのでしょうか? YARDであれば、ソース以外にテキストファイルもドキュメントに加 えられるので、テキストファイルに書く方がよいと思います。たと えば、これもソースとは別のファイルに書かれていると思います。 http://rubydoc.info/docs/yard/0.7.1/file/docs/GettingStarted.md > TARGET_NAMESPACEを隠蔽しようとしているのは、1ファイル=1名前空間を強制させる意味が大きく > ちょっとやりすぎ感は確かにあるのですが、この方式にしたいです。 わかりました。 では、そうしましょう。 >> LispとかRuby本体ではpredicateな関数・メソッド(述語。真偽値 >> を返す関数・メソッド)に?をつけるので、_qではなく_pの方がい >> いかなぁと思いました。 > > predicateと言うのですか。 > では、_pでいいですかね。 では、_pにしましょう。 >>> * ! 付きメソッドの関数名は、末尾に ! の代わりに _e を付ける >>> 使用マクロ:G_DEF_METHOD_E >> >> eはexclamationの略ですよね。 >> Ruby本体ではbangを使っているのでそっちにあわせる方がいいかなぁ >> と思いましたが、_bだとなんだかわからないんですよねぇ。_bang >> でもいい気がしますが、1文字がいいんですよね。うーん。 > > ! 付きメソッドは、それほど多くないはずなので、_bangでいいですかね。 では、こちらは_bangで。 > すみません、今調べたらrg_もrgb_も使っている箇所がありましたが、どうしましょう? > マクロのprefixも新たにしてマクロの整理も行う方向に持っていけたらベストでしょうか。 そうですね。 ざっと見てみたら、rg_よりもrbg_の方が多いので、rbg_に統一す る方向でいきましょう >> やり過ぎ感をもう少し書いておくと、一回リポジトリからremoveす >> る前のRuby/GIO2みたいな方向になっていくのを危惧しています。 >> ソースコードを見てもらえばわかると思うのですが、「たしかに >> Rubyの拡張ライブラリを作っているCなんだけど、違う言語に見え >> る」、という感じになっています。 >> >> r3724で削除したので、これで見れると思います。 >> http://ruby-gnome2.svn.sourceforge.net/viewvc/ruby-gnome2/ruby-gnome2/trunk/gio/?pathrev=3723 > > なるほど、似たようなことをやってらっしゃいますね。。。 > ただ、自分が考えているのは実装やドキュメントの不足チェックとテンプレート生成を自動化することが主な目的なので、 > 関数定義の部分まで手を突っ込むことはないと思います。 わかりました! では、この方向でいきましょう! |