コメント: Re:楽勝です (スコア 1) 138
このトピックへの返信はこれで最後にします。
●「eq」というメソッド名について
> 挙げられてる例はどれもクエリの組み立てなんかに使うもので、
SAStrutsのeqは内容の一致を表すので、同値比較ですよ。
また、制約ソルバや抽象構文木の同値比較ノードの場合、
意味的には同じことではないでしょうか。
(操作をデータとして表しただけなので)
それとも、返値の型がbooleanでオブジェクト間の同値比較を行う
メソッド以外は全部別物扱いということでしょうか?
そうだとしたら、問題設定自体に無理があります。
2つのObjectを引数にとるstaticメソッドの同値比較は
標準APIに存在せず、個々の開発者が自作しているはずです。
(つまり、どの慣習のことも支持しない)
また、rhsだけを取るインスタンスメソッドが「equals」なのは
慣習ではなく仕様なので、慣習が使われる余地はありません。
仕様で決まっていないメソッド名を、どの慣習に従って付けるか、
という話ですよね?
> 同値比較メソッドの名前が「eq」と「equals」のどちらが一般的ってのは、
どちらがより一般的かを決める必要は無いんですよ。
二つの慣習が併存する場合もありますので。
(一つのソースコードツリー内では統一すべきですが)
別の言い方をすると、ある慣習を使うか使わないかは、
どの慣習の使用数が一位かを決めるという話ではないのです。
> 繰り返しにしかなりませんが、
> 同値比較メソッドの名前をeqとする慣習はありません。
上で書いたように、前回挙げた例が慣習の例になっていると思います。
●なぜ「eq」のような慣習がJavaにも入ってきているのか
以下は私の個人的な意見ですが。
Javaが作られた時代は、意味不明な省略形が横行していた暗黒時代でした。
Javaの長く説明的な名前はそれを解消し、名前付けの重要性を示しました。
一方で、Javaも既に15年近く経過し、コード量の多さを批判されるように
なりました。
(Web開発ではしばらく前に、大真面目にRubyと比較されていました)
いくつか根拠が挙げられていますが、その一つが説明的なメソッド名です。
通常のメソッドには説明的な名前が必要ですが、極めて高頻度に使用され、
かつ一般的なメソッドだけは、短くすべきではないか、と考える人がいる
ということだと思います。
(どうせ暗記して使うので)
例えば「int」が「integer」ではないからといって、分かりにくいと思う
人はいないでしょう。
慣習というのは、良いと思う人は使い、使う人が増えれば一般的になります。
新しく、生産性を上げようとするフレームワークで「eq」のような名前が
採用されているということは、その慣習がJavaの文化にも入ってきている
最中なのでしょう。
さらに多くのフレームワークやライブラリで採用され、
より一般的になれば、いずれ違和感は感じなくなると思います。
他の言語の文化から慣習が入ってくるのを「今までのJavaと違う」
というだけで拒否し続けると、改善が見込めなくなるのではないでしょうか。
# 昔のJava文化なら「ge」は「isGreaterThanOrEquals」としたでしょう。
●なぜ「くだらない」と言われるのかについて
私が思うに、命名規則の話をするのがくだらないと言われている
わけではないと思います。
> 特に違和感はないです。
結局のところ、これに尽きるのではないでしょうか。
自分自身が見慣れているか否かという話になっている点です。
他の方々は、色々経験すれば変わると思い、経験の代わりに
各自のC++などでの経験談を伝えてくれているのだと思います。
●その他
> ましてや、あんな基礎的なNullPointerExceptionの防ぎ方を「参考になる」とするような
> 初心者に提示するサンプルコードとしては不適切としかいいようがない。
最初からプログラマ向けのスレッドなので、
皆さんプログラミング自体の初心者ではないでしょう。
(スラドには猛者も多いです)
おそらく「Javaでは」どうなのかが参考になったのでは。
(件のコードのメソッド名はもう少しで「hoge」になるところでした)
●「eq」というメソッド名について
> 挙げられてる例はどれもクエリの組み立てなんかに使うもので、
SAStrutsのeqは内容の一致を表すので、同値比較ですよ。
また、制約ソルバや抽象構文木の同値比較ノードの場合、
意味的には同じことではないでしょうか。
(操作をデータとして表しただけなので)
それとも、返値の型がbooleanでオブジェクト間の同値比較を行う
メソッド以外は全部別物扱いということでしょうか?
そうだとしたら、問題設定自体に無理があります。
2つのObjectを引数にとるstaticメソッドの同値比較は
標準APIに存在せず、個々の開発者が自作しているはずです。
(つまり、どの慣習のことも支持しない)
また、rhsだけを取るインスタンスメソッドが「equals」なのは
慣習ではなく仕様なので、慣習が使われる余地はありません。
仕様で決まっていないメソッド名を、どの慣習に従って付けるか、
という話ですよね?
> 同値比較メソッドの名前が「eq」と「equals」のどちらが一般的ってのは、
どちらがより一般的かを決める必要は無いんですよ。
二つの慣習が併存する場合もありますので。
(一つのソースコードツリー内では統一すべきですが)
別の言い方をすると、ある慣習を使うか使わないかは、
どの慣習の使用数が一位かを決めるという話ではないのです。
> 繰り返しにしかなりませんが、
> 同値比較メソッドの名前をeqとする慣習はありません。
上で書いたように、前回挙げた例が慣習の例になっていると思います。
●なぜ「eq」のような慣習がJavaにも入ってきているのか
以下は私の個人的な意見ですが。
Javaが作られた時代は、意味不明な省略形が横行していた暗黒時代でした。
Javaの長く説明的な名前はそれを解消し、名前付けの重要性を示しました。
一方で、Javaも既に15年近く経過し、コード量の多さを批判されるように
なりました。
(Web開発ではしばらく前に、大真面目にRubyと比較されていました)
いくつか根拠が挙げられていますが、その一つが説明的なメソッド名です。
通常のメソッドには説明的な名前が必要ですが、極めて高頻度に使用され、
かつ一般的なメソッドだけは、短くすべきではないか、と考える人がいる
ということだと思います。
(どうせ暗記して使うので)
例えば「int」が「integer」ではないからといって、分かりにくいと思う
人はいないでしょう。
慣習というのは、良いと思う人は使い、使う人が増えれば一般的になります。
新しく、生産性を上げようとするフレームワークで「eq」のような名前が
採用されているということは、その慣習がJavaの文化にも入ってきている
最中なのでしょう。
さらに多くのフレームワークやライブラリで採用され、
より一般的になれば、いずれ違和感は感じなくなると思います。
他の言語の文化から慣習が入ってくるのを「今までのJavaと違う」
というだけで拒否し続けると、改善が見込めなくなるのではないでしょうか。
# 昔のJava文化なら「ge」は「isGreaterThanOrEquals」としたでしょう。
●なぜ「くだらない」と言われるのかについて
私が思うに、命名規則の話をするのがくだらないと言われている
わけではないと思います。
> 特に違和感はないです。
結局のところ、これに尽きるのではないでしょうか。
自分自身が見慣れているか否かという話になっている点です。
他の方々は、色々経験すれば変わると思い、経験の代わりに
各自のC++などでの経験談を伝えてくれているのだと思います。
●その他
> ましてや、あんな基礎的なNullPointerExceptionの防ぎ方を「参考になる」とするような
> 初心者に提示するサンプルコードとしては不適切としかいいようがない。
最初からプログラマ向けのスレッドなので、
皆さんプログラミング自体の初心者ではないでしょう。
(スラドには猛者も多いです)
おそらく「Javaでは」どうなのかが参考になったのでは。
(件のコードのメソッド名はもう少しで「hoge」になるところでした)