[#21157] あったらうれしいメソッド to_n, to_n!, to_s! — ogino@...

荻野です。あったらうれしいメソッドということで書いてみます。

16 messages 2000/03/03

[#21159] メソッドの入り口 — ogino@...

荻野です。もうひとつご指導ください。

93 messages 2000/03/03
[#21170] Re: メソッドの入り口 — Shin-ichiro Hara <sinara@...> 2000/03/03

原です。

[#21243] Re: メソッドの入り口 — keiju@... (石塚圭樹) 2000/03/07

けいじゅ@日本ラショナルソフトウェアです.

[#21247] Re: メソッドの入り口 — 中村暁史 Nakamura Akifumi <BXQ04723@...> 2000/03/07

[#21267] 引数コピーとオブジェクト指向 (Re: メソッドの入り口) — Hideto ISHIBASHI <s34204@...> 2000/03/08

石橋秀仁です。

[#21272] Re: 引数コピーとオブジェクト指向 (Re: メソッドの入り口 ) — 中村暁史 Nakamura Akifumi <BXQ04723@...> 2000/03/08

[#21276] Re: 引数コピーとオブジェクト指向 (Re: メソッドの入り口 ) — nobu.nakada@... 2000/03/09

なかだです。

[#21279] Re: 引数コピーとオブジェクト指向 (Re: メソッドの入り口 ) — ogino@... 2000/03/09

oop未満の世界観の荻野です。

[#21282] Re: 引数コピーとオブジェクト指向 — Tomoyuki Kosimizu <greentea@...2.so-net.ne.jp> 2000/03/09

越水です。

[#21285] Re: 引数コピーとオブジェクト指向 — ogino@... 2000/03/10

荻野です。

[#21293] Re: 引数コピーとオブジェクト指向 — Matsuo Hisanori <hisanori@...> 2000/03/10

松尾です。

[#21297] Re: 引数コピーとオブジェクト指向 — ogino@... 2000/03/10

荻野です。

[#21302] Re: 引数コピーとオブジェクト指向 — 土岐 仁謙 <toki@...> 2000/03/10

土岐です。

[#21371] Re: 引数コピーとオブジェクト指向 — Matsuo Hisanori <hisanori@...> 2000/03/13

松尾です。

[#21374] Re: 引数コピーとオブジェクト指向 — TADA Tadashi <sho@...> 2000/03/13

ただただしです。

[#21365] Re: 引数コピーとオブジェクト指向 — Matsuo Hisanori <hisanori@...> 2000/03/13

松尾です。

[#21280] raise non-Exception object — Kenichi Komiya <kom@...3.rim.or.jp>

24 messages 2000/03/09
[#21283] Re: raise non-Exception object — nobu.nakada@... 2000/03/09

なかだです。

[#21315] Re: raise non-Exception object — Kenichi Komiya <kom@...3.rim.or.jp> 2000/03/11

[#21342] Re: raise non-Exception object — nobu.nakada@... 2000/03/12

なかだです。

[#21384] ruby 1.4.4 — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

35 messages 2000/03/13

[#21442] 配列内のソート — Takayuki Tanaka <tanaka@...>

こんにちは Tanです。

16 messages 2000/03/15

[#21583] ruby for Web — TAKAHASHI Masayoshi <maki@...>

高橋征義です。

27 messages 2000/03/22
[#21584] Re: ruby for Web — "NAKAMURA, Hiroshi" <nakahiro@...> 2000/03/22

なひです.

[#21649] net-1.1.10 — TAKAHASHI Masayoshi <maki@...>

高橋征義です。net/http 使いたおし中。

17 messages 2000/03/27

[#21669] new version of mod_ruby & eRuby — Shugo Maeda <shugo@...>

前田です。

14 messages 2000/03/28

[ruby-list:21297] Re: 引数コピーとオブジェクト指向

From: ogino@...
Date: 2000-03-10 13:03:09 UTC
List: ruby-list #21297
荻野です。

個人的にはひとつの結論に収束する話題とは思いませんし、収束しないままで
もいろいろ得るものも多かったので感謝しております。

とりあえず自分の意見のまとめとして、1) 「カプセル化」という言葉をどう
感じるか、2) 実際問題として Ruby では dup しなくても良いし、されている
と期待するな、ドキュメントやコードを読みなさい、3) 問題は全部の窓が同
じ権利をもっていることにあり dup というのは単にそれが引き起こす危険を
避けるための方便にすぎない(Rubyでは他の方法が提供されていない)ではない
かという考え、の三つを書いてみました。


At Fri, 10 Mar 2000 16:28:52 +0900,
Matsuo Hisanori <hisanori@sitc.toshiba.co.jp> wrote:

> > そりゃそうなんですけど、Person クラスの設計者とその利用者が同じでない場
> > 合、利用者は Person クラスの内部コードまでは意識しないので、name.sub!を
> > やっちゃうかもしれませんよね。
> 
> 開発者向けの話とすると…。
> 
> やっちゃうかもしれない、かもしれないけど、使う時に大体分かりませんか? 
> このデータは何の為に渡してるか、って視点で見ると。不安ならちゃんと注意
> してドキュメント読むとか。僕が使う側ならそうします。
> 
> 要するにPersonクラスの責任でなくて、使う側の責任。

# dup するかどうかを(ライブラリ)開発者向けの話としても、使う側が開発者
# (って?)とは限りませんよね。ここではその話は置いておきますが。

1) 「不安ならちゃんと注意してドキュメント読むとか」を使う側の責任とす
るのは私の思う「カプセル化」とは違います。

ここで言う「ドキュメントを読む」というのは初期化とかのために与えた引数
がクラス内部でどう扱われているかということを気にするという意味だと思え
るのです。クラス内部の実装を気にしないと使えないクラスというのは「カプ
セル化」がきちんとされていないクラスと私なら感じてしまいます。


それにドキュメントなりコードなりを読んで、Person に与えたオブジェクト
を引っ掻き回してはいけないんだと分かったとして、使う側が安全のために

name = 'John'
  :
john = Person.new (name.dup)
  :
  :
name.sub! (....)

とすれば良い.... とは思えないからです。Person.new (name) としたときに
直感的に Person has a name と思うからです。しかし、

class Person
  def initialize(name)
    @name = name
    @friends = Array.new
  end

  def make_friends_with (friend)
    @friends << friend
  end
end

とするときは Person knows his friends で所有(has)の関係ではないので、
friend が改名しようがしまいがかまいません。でもインスタンス変数は所有
している(べき)ものを指すことが多いのではないでしょうか。


2) しかしながら、「オブジェクト指向におけるカプセル化」というのが何を
指すかという議論とは別に、dup によって自分だけのオブジェクトをつくらな
くても、実際問題として困らないというお話は実際に Ruby を長く使っている
方からだけに説得力があります。

少なくとも Ruby では、他の方のつくったライブラリを利用するときにおいて、
引数にもつかったオブジェクトを変化させるときは、内部の実装上問題がない
かをドキュメントなりコードなりを読んで判断するべきであるという基準で作
成されていると想定するべきなのは明らかです。

したがって、ドキュメントをよく読み内部を把握してから使うか、または引数
に与えるときに複製を与えるなり、または変化させないように name.sub! で
はなく name = name.sub を使用するなりするべきだということですね。逆に
他の人(または一年後の自分)につかってもらうことを想定するライブラリ内に
おいては dup をする必要は普通はない。それは利用者の責任である、と。こ
れを Ruby 流と呼ぶ?


3) なんとなく継承とは別にメソッドのアクセス権が設定できれば dup せずに
広い意味でもカプセル化を実現できるのかな、とも思えてきます。外側に開い
た窓を閉じる(変数の消失?)というのは構文上無理がありそうですが、窓から
投げ込まれるメッセージをアクセス権により例えば sub は許可、sub!  は不
許可と設定できればいいわけです。しかし、このアクセス権は窓つまり変数に
属するので Ruby とは全然別の言語になってしまいますね。

class Perosn
  def initialize (name)
    @name = name
  end

  def change_name (new_name)
    @name.sub! (/.*/, new_name) # ちょっと無理がありますが例です
  end
end

name = 'John'
john = Person.new (name)

において Person のもつ窓 @name からは sub! メッセージを通すが、所有権
を失った窓 name からは sub は通っても sub! は禁止とか。所有権(という言
葉も変ですが)とその移転をどう表現するかとか考えているわけではないので
すが。なお窓(変数)単位ではなくメッセージの送信者毎でも同じことです。

こう考えると、今までのみなさんの議論は上記の制限を言語ではなく人間が注
意するという話のように思います。注意すれば良いから dup 不要、注意する
とかしないとか考えさせたくないから or 安全を保障したいから dup する、
とかですが、多分こういったアクセス制限ができれば dup は誰からもほとん
ど不要という結論になるかもしれませんね。


# もちろん Ruby ユーザの多くの方が現状で満足されているようなので、この
# 機能を Ruby が実装したほうが良いとはあまり思えません。


結局、機能の豊富なライブラリを気軽に(中はどうなっているか気にせずに)使
えて、使い方を間違えたらエラーがでて教えてくれる、というのが有難いので
す。でも、今の Ruby でも十分すぎるぐらい有難いです。長くなってすみませ
ん。


-- 
荻野 充 (おぎの みつる) ... 「萩(はぎ)」にあらず
名古屋大学消費生活協同組合

In This Thread