[ruby-dev:40255] Re: [Feature #2366] private constant

遠藤です。

大体成瀬さんが返事してくれている通りですが。


2010年1月30日7:08 Masatoshi SEKI <[e-mail]>:
>>> うーん。そうするとそう宣言しなかったものは、どうなるんでしょう。
>>>
>>> 「変えないって言ったのに変更しやがって！」と怒られるとか？
>>
>> 「変えない」と言った覚えはないわけですが、
>> 公開APIである以上安易な仕様変更は慎む事が期待されます。
>> そもそも、Rails 以降 Ruby でも仕様変更は控えることが期待されつつあります。
>
> では「慎むっていったのに変更しやがって！」でしょうか。
> private constantがあれば
> 「変更しやがって！でもprivate constantだから勘弁してやる」
> みたいな感じ？
>
> どっちにしてもぎゃって思われそうだけどなあ。

ぎゃっとなるのは、そもそも内部クラスとか不用意に使うからですよね。
使ってなければぎゃっとなることもないです。
なぜ使ってしまうかというと、言語レベルでそれを注意喚起する仕組みが
ないからだと思うのです。

まあ、:nodoc: って書いてあれば使うなよ……という気もするのですが、
rubyspec が「private は仕様にしない、でも :nodoc: は仕様にする」と
いう立場だったので、そう考える人も多いんでしょうねえ。Rails とか。


あと、よく考えたら、咳さんが最初に気にしていたのは、ユーザが一部の
API や実装を勝手に再定義した場合でしたっけ。そういうのはさすがに、
何が起きても自己責任というコンセンサスがあると思います。


> 言語仕様だとしたらPure Rubyなライブラリの挙動を
> specに記述する必要あるのか疑問です。
> だってそのままもってくれば同じように動くはずだもん。

spec なので、ライブラリの spec を詳しく知りたいときに読むもの、を
目指してもいるようです (現状それが達成されているかはさておき) 。
「コードが仕様」ではなくて。

また、最適化や独自拡張をするときに conformance test にも使えると
思います。そのために rubyspec では、「引数をわざと多く与えたときに
例外が投げられる」みたいな、独自拡張を妨げるような spec は書かない、
という方針になってます (現状それが達成されているかはさておき) 。


>> それでも仕様変更であると宣言するならばもちろん変更は可能です。
>
> わかりました。ありがとうございます。

可能ではありますが、極力避けるべきではあります。

-- 
Yusuke ENDOH <[e-mail]>