[#38080] ポートが閉じているときの例外など — Mitsuru Ogino <ogino@...>

荻野と申します。いつも質問や要望ばかりですみません。

36 messages 2003/08/11
[#38086] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/12

なかだです。

[#38088] Re: ポートが閉じているときの例外など — IWAOKA Masahiro <iwaoka@...> 2003/08/12

いわおかです。

[#38091] Re: ポートが閉じているときの例外など — Mitsuru Ogino <ogino@...> 2003/08/12

荻野です。

[#38092] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/12

なかだです。

[#38093] Re: ポートが閉じているときの例外など — IWAOKA Masahiro <iwaoka@...> 2003/08/12

いわおかです。

[#38095] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/12

In message <20030812150516.GV37221@barber.fe.rn.tuat.ac.jp>

[#38102] Re: ポートが閉じているときの例外など — Tetsuo NAKAGAWA <tet@...> 2003/08/14

中川と申します。

[#38121] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/15

In message <20030814.140757.707824131.tetsuo@sapphire.siz.nes.nec.co.jp>

[#38123] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/16

なかだです。

[#38130] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/16

In message <200308160517.h7G5HcPL012839@sharui.nakada.kanuma.tochigi.jp>

[#38137] Re: ポートが閉じているときの例外など — nobu.nakada@... 2003/08/18

なかだです。

[#38139] Re: ポートが閉じているときの例外など — Takahiro Kambe <taca@...> 2003/08/18

In message <200308180959.h7I9xnb7001977@sharui.nakada.kanuma.tochigi.jp>

[#38122] ruby-tcpwrap and mkmf.rb — Takahiro Kambe <taca@...>

こんにちは。

16 messages 2003/08/16
[#38125] Re: ruby-tcpwrap and mkmf.rb — "Akinori MUSHA" <knu@...> 2003/08/16

At Sat, 16 Aug 2003 12:51:55 +0900,

[#38183] String << の動作につきまして — kuto@...

うと と申します。

44 messages 2003/08/22
[#38187] Re: String << の動作につきまして — Take_tk <ggb03124@...> 2003/08/22

たけ(tk)です。

[#38189] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38190] Re: String << の動作につきまして — Take_tk <ggb03124@...> 2003/08/23

たけ(tk)です。

[#38191] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38194] Re: String << の動作につきまして — Take_tk <ggb03124@...> 2003/08/23

たけ(tk)です。

[#38196] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38203] Re: String << の動作につきまして — 西 啓一朗 <receiver@...> 2003/08/23

ども、西啓一朗@Ktouth Brand. です。

[#38208] Re: String << の動作につきまして — Tadayoshi Funaba <tadf@...5.so-net.ne.jp> 2003/08/23

ふなばです。

[#38211] Re: String << の動作につきまして — 西 啓一朗 <receiver@...> 2003/08/24

ども、西啓一朗@Ktouth Brand. です。

[#38195] 理解の進め方(Re: String << の動作につきまして) — Tadashi Oh-Ya <toy@...>

おおやです。

36 messages 2003/08/23
[#38206] 理解の進め方:シュールな世界 — Take_tk <ggb03124@...> 2003/08/23

たけ(tk)です。

[#38233] シュールな名前 — Take_tk <ggb03124@...> 2003/08/25

たけ(tk)です

[#38198] Tmailで送るメールに日付がつけられなくなりました — 川田誠司 <kawada.seiji@...>

はじめまして

11 messages 2003/08/23

[#38256] かみ砕いた説明をすべき範囲 — 西 啓一朗 <receiver@...>

ども。西啓一朗@Ktouth Brand. です。

41 messages 2003/08/26
[#38258] Re: かみ砕いた説明をすべき範囲 — nobu.nakada@... 2003/08/26

なかだです。

[#38261] Re: かみ砕いた説明をすべき範囲 — Take_tk <ggb03124@...> 2003/08/26

たけ(tk)です

[#38262] Re: かみ砕いた説明をすべき範囲 — nobu.nakada@... 2003/08/26

なかだです。

[#38264] Re: かみ砕いた説明をすべき範囲 — Take_tk <ggb03124@...> 2003/08/26

たけ(tk)です

[#38265] Re: かみ砕いた説明をすべき範囲 — IWAOKA Masahiro <iwaoka@...> 2003/08/26

いわおかです。

[#38267] Re: かみ砕いた説明をすべき範囲 — Take_tk <ggb03124@...> 2003/08/26

たけ(tk)です

[#38273] Re: かみ砕いた説明をすべき範囲 — matz@... (Yukihiro Matsumoto) 2003/08/26

まつもと ゆきひろです

[ruby-list:38300] 配列における「変数のモデル」

From: Take_tk <ggb03124@...>
Date: 2003-08-30 17:47:06 UTC
List: ruby-list #38300
たけ(tk)です。

> |もう一つ悩んだのは、「配列やハッシュというオブジェクトとその要素・値とな
> |るオブジェクトとの関係」と「変数とオブジェクトとの関係」は本質的に異なる
> |ものなのか? ということ。
> |
> |名前説をとった場合に配列と変数が似た性質を持つことをどうやって説明しましょ
> |うか? 配列も要素オブジェクトの名前だ(※)、となるのか?

 配列は「オブジェクトを順番に並べたもの、であるかの如く振る舞うように設
計されたオブジェクト」である。ハッシュは「キーと値という形で関連つけられ
たオブジェクトの組みの集まり、であるかの如く振る舞うように設計されたオブ
ジェクト」である。

 それらのオブジェクトのインデックス代入メソッドとインデックス参照メソッ
ドは、「配列[インデックス]があたかも変数である、かの如くに振る舞うように
設計されたメソッド」である。

 オブジェクトの隠蔽性を念頭に置くなら、配列やハッシュがどのように実現さ
れているか、どういう仕組みになっているか、その内部構造が変数と似ているか
どうか、は不可知であり、詮索することは無意味なことである。

 しかしながら、「あたかも変数であるかの如くに振る舞う」という仕様は「変
数をモデルとして設計された」ということであるから、そこに含まれる変数のモ
デルを知ることには意味がある。

1. 変数のモデルの要素

 まず、Rubyの変数のモデルを記述するために必要な要素、機能を考えてみた。

(1)変数とオブジェクトは別のもの。

(2)変数自体はオブジェクトではない。

(3)変数には名前がある。変数名。

(4)変数は特定のオブジェクトを指し示す。変数はオブジェクトを特定する。

(4−1)変数によって指し示されたオブジェクトは、自分を指し示した変数を
知らない。たとえ知ることができたとしても、変数とオブジェクトとの関係の本
質には無関係。

(4−2)1つの変数は1つのオブジェクトを指し示す。複数のオブジェクトを
指し示すことはない。何も指し示さないということも無い(nilオブジェクトを
指し示す)。

(4−3)複数の変数が1つのオブジェクトを指し示すことはあり得る。この場
合には複数の変数が同じ内容を示す。

(4−4)異なった複数のオブジェクトが同一内容を持つ場合がある。複数の変
数がそれぞれ別のオブジェクトを指し示しているときに、それらが同じ内容を示
すことがあり得る。

(4−5)−3と−4では、破壊的メソッドを使ったときに、異なった結果にな
る。従って、これを区別する必要がある。

(5)変数が指し示すオブジェクトを変更することができる。これを代入という。

(5−1)変数の値が変わる、といっても、代入によって変数が指し示している
オブジェクトが入れ替わる場合と、破壊的メソッドによって変数が指し示してい
るオブジェクトの状態が変わる場合とがある。

(6)変数を通してオブジェクトを利用可能にする/操作可能にする/対話可能
にすることを参照という。

(6−1)オブジェクトは直接扱うことはできない。オブジェクトを変数から
「取り出す」ことは出来ない。

1. インデックス代入/参照メソッドのモデル

 配列やハッシュのインデックス代入/参照メソッドで「あたかも変数であるか
の如くに振る舞う」という仕様から、そこに含まれる変数のモデルを想定してみ
ると次のようになった。

(1)配列[インデックス]と要素のオブジェクトは別のもの。

(2)配列[インデックス]自体はオブジェクトではない。

 配列[インデックス]は「変数であるかのごとく設計されたメソッド」なのであ
るから、配列[インデックス]は変数ではない、ということは問題とはならない。

(3)配列[インデックス]は名前を持っているわけではない。●

 配列[インデックス]は名前ではあり得ない。配列はオブジェクト、インデック
スもオブジェクトである。

 変数は名前によってオブジェクトを特定するが、配列[インデックス]において
は《名前ならざるもの》によってオブジェクトを特定する。

(4)配列[インデックス]はオブジェクトを指し示す。一方通行。

(4−1)配列[インデックス]によって指し示されたオブジェクトは、自分を指
し示した配列[インデックス]を知らない。

(4−2)1つの配列[インデックス]は1つのオブジェクトを指し示す。複数の
オブジェクトを指し示すことはない。何も指し示さないということも無い(nil
オブジェクトを指し示す)。

(4−3)複数の配列[インデックス]が1つのオブジェクトを指し示すことはあ
り得る。この場合には複数の配列[インデックス]が同じ内容を示す。

(4−4)異なった複数のオブジェクトが同一内容を持つ場合がある。複数の配
列[インデックス]がそれぞれ別のオブジェクトを指し示しているときに、それら
が同じ内容を示すことがあり得る。

(4−5)−3と−4では、破壊的メソッドを使ったときに、異なった結果にな
る。従って、これを区別する必要がある。

(5)配列[インデックス]が指し示すオブジェクトを変更することができる。こ
れをインデックス代入という。

(5−1)配列[インデックス]の値が変わる、といっても、インデックス代入に
よって配列[インデックス]が指し示しているオブジェクトが入れ替わる場合と、
破壊的メソッドによって配列[インデックス]が指し示しているオブジェクトの状
態が変わる場合とがある。

(6)配列[インデックス]を通してオブジェクトを利用可能にする/操作可能に
する/対話可能にすることをインデックス参照という。

(6−1)オブジェクトは直接扱うことはできない。オブジェクトを配列[イン
デックス]から「取り出す」ことは出来ない。

1. 対比から得られる結論

 この対比から得られる結論は、配列[インデックス]は変数が有する特徴のうち、
変数は名前を持つ、ということを除いたものをすべて備えているということ。

 従って「変数であるかの如く振る舞う」ためには名前である必要はない。とい
う結論になる。何らかの方法で、指し示すオブジェクトを特定できればよいので
あって、その方法が名前である必要はない、ということ。

take_tk = kumagai hidetake

In This Thread