[ruby-dev:14099] Is private instance variable really needed?

前田です。
今あんまり仕事に余裕がないので、深く考察しきれていないのですが。

At Wed, 25 Jul 2001 16:45:15 +0900,
[e-mail] (Yukihiro Matsumoto) wrote:
> まあ、現時点でインスタンス変数がサブクラスに公開されているの
> はそれが理由ですよね。
> 
> ただ、それは「たまたま名前が重なってしまう」ことに対しては無
> 力なんですよね。特にAPIと関係ない単なる実装であるはずのイン
> スタンス変数名まで重複しないように気を使うとなると、本末転倒
> な気がします。

名前の衝突に対する回避策として、本当にprivate instance variable
が適切な解なのでしょうか。

private instance variableというのはサブクラスに対して制限を加える
ものですよね。
あるクラスを設計する時に、そのクラスがサブクラスでどのように拡張
されるかは予測できないので、サブクラスからはAPIだけではなく、すべ
ての実装にアクセスできるべきなのではないかと思います。

インスタンス変数はたんなる実装なので、問題は名前が衝突することで
はなく、衝突を検出できないことなんじゃないでしょうか。
衝突が検出できれば、インスタンス変数は外部に公開するものではない
ので、名前を変えることに抵抗はないと思います。
# Mix-inによるメソッド名の衝突はそうも行きませんが…。

そこで、たとえば、

(1) initializeですでに初期化されているインスタンス変数に代入した
    場合には警告を出す。(もしくはエラーにする)
(2) private instance variableはサブクラスによって参照はできるが、
    代入はエラー。
    (したがってサブクラスでスーパークラスと同じ名前の違うprivate
    instance variableを利用することはできない。)

といった解決はどうかなと考えました。

また、完全なprivate instance variableを導入するとしても、不自然で
はないAPIでサブクラスからのアクセスを許すようにしてほしいです。

> というのがプライベートインスタンス変数導入の動機なんですよね。
> ま、実際Little Smalltalkのようにインスタンス変数は自分からし
> か見えないって言語もありますし。C++もデフォルトはprivateです
> よね。C++の良い点ってこれしか思いつかないという...。

それはよい点なのかなあ。
宣言があれば名前の衝突を検出できるので、privateである必要はないよ
うな気がします。

> 別の極端としてはEiffelのselected export(やClassicのprofile)
> のように誰から見えるかを明示する方法がありますね。

Eiffelはあまりよく知らないのですが、サブクラスに対してはすべての
featureが公開されていて、selected exportで指定するのは継承関係に
ないクラスなのではないでしょうか?
とすると、ちょっと文脈が違うような気がします。

-- 
前田 修吾