オブジェクト指向の活用方法を教えて下さい

**デフォルトの名無しさん** · 2014/03/25(火) 21:44:07.66

お願いします。言語は問いません。
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。

**デフォルトの名無しさん** · 2014/04/03(木) 15:05:44.04

>>188
ちゃんとしたSmalltalk処理系では（つまりGNU Smalltalkとかの変わり種を除けば）一般に
value foo halt bar baz で、bar のコール直前でデバッガを起動させて bar のステップ実行ができる
ってそういうことではなく？　ちなみに halt は古典的なSmalltalkにおけるブレイクポイントみたいなもの。

**デフォルトの名無しさん** · 2014/04/03(木) 15:25:06.01

みんなSmalltalk使ってたのかよ

**デフォルトの名無しさん** · 2014/04/03(木) 17:07:01.60

スモールトークがオブジェクト指向の元祖だからな
スモールトークでできるならオブジェクト指向の欠点とは胃炎な

**デフォルトの名無しさん** · 2014/04/03(木) 17:16:43.96

ていうか、一つの式に詰め込んだら便利かどうかなんてオブジェクト指向と関係なくね？

**デフォルトの名無しさん** · 2014/04/03(木) 19:17:35.74

Smalltalkには、コードを英文のように読み下せるように書く慣習みたいなものがあって、
value foo bar baz みたいな式だとちょっとメリットをイメージしにくいですが、たとえば
「1 から 9 までの数を配列にして、それをシャッフルして最初の３つを得る」みたいな処理を、
(1 to: 9) asArray shuffled first: 3 というふうに一気にメソッドチェーンにして書くようなことはよくします。

そんなこともあって、メソッドチェーンだからデバッグしづらいというような制約はほとんどうけない仕組みになっています。

**デフォルトの名無しさん** · 2014/04/03(木) 20:08:44.08

>>194
そもそもオブジェクト指向についてあんまり語ってないからいいんじゃね

**デフォルトの名無しさん** · 2014/04/03(木) 21:23:31.55

>>191
なるほど、ブレーク+ステップ実行なのね
まあ実用上は十分かな
C# とかでもできるようにしてほしい

**デフォルトの名無しさん** · 2014/04/04(金) 00:28:50.72

C++じゃなくてObjective-Cが流行ってれば
オブジェクト指向絡みの論争は半分になったんじゃないかと
思えてしかたがない。
オブジェクト指向が、じゃなくてC++が採用した方法は、な議論大杉

**デフォルトの名無しさん** · 2014/04/04(金) 01:37:59.49

クラスベース vs プロトタイプベース

**デフォルトの名無しさん** · 2014/04/04(金) 01:52:31.25

Objective-C十分流行ってるじゃん

**デフォルトの名無しさん** · 2014/04/04(金) 03:12:14.91

ここ5年ぐらいでiOS用で一気に拡まったけど90年代を通じて
一般の想定するオブジェクト指向と言ったらC++だったからな…
90年代後半からはそこにJavaが加わり…的な。
ある意味バカみたいに基本に忠実なObjective-Cの方が
オブジェクト指向とは～って議論のたたき台としてはよかったよな的な。

**デフォルトの名無しさん** · 2014/04/04(金) 07:15:48.10

>>197
と言うか、行単位でのブレークポイントなのはデバッガの都合でしかないんだよなあ

**デフォルトの名無しさん** · 2014/04/04(金) 07:36:28.20

>>202
式の途中にブレークポイントを入れるのはデバッガだけでは無理っす。

**デフォルトの名無しさん** · 2014/04/04(金) 08:06:13.57

>>203
いや、だからそれって今のデバッガだからだろ？
技術的にできない訳じゃなかろ

**デフォルトの名無しさん** · 2014/04/04(金) 09:05:42.51

最低限、コンパイラにも手を入れる必要があると思うぞ。

**デフォルトの名無しさん** · 2014/04/04(金) 10:52:39.43

デバッガのブレークポイントの指定が
行単位ってだけで、関数単位でのステップは可能。

そして関数単位で止めたいなら
関数ごとに改行すればいいだけじゃない。

**デフォルトの名無しさん** · 2014/04/04(金) 13:07:13.88

>>206
> デバッガのブレークポイントの指定が行単位ってだけで、

たいていの IDE は行単位ではなくてステートメント単位じゃね？

> 関数ごとに改行すればいいだけじゃない。

そもそもそんなことしたくないか、発端だろ。
デバッグのためにソース弄るとかは最後の手段だろ。

**デフォルトの名無しさん** · 2014/04/05(土) 08:19:53.84

>>206
だーかーらー、
コンパイラが出す行情報以外にどうやって
ブレークかけるアドレスを取り出すわけ？
関数ごとに改行したところで
普通のコンパイラはステートメント単位でしか行番号情報ださねーぞ。

もしかして、単にデバッガのUIの問題だと思ってた？
甘杉

**デフォルトの名無しさん** · 2014/04/05(土) 08:39:06.87

そういうスレたててやれ

**デフォルトの名無しさん** · 2014/04/05(土) 10:05:58.71

いったいどのデバッガやコンパイラについて話してるのか知らんが、
VS2013とかにはメソッドチェーンのデバッグ機能あるぞ……
メソッドチェーン中の個々のメソッドについて戻り値とその型を表示してくれる

**デフォルトの名無しさん** · 2014/04/05(土) 12:34:58.04

>>1
mvcで作ればなんとなくわかる

**デフォルトの名無しさん** · 2014/04/05(土) 21:29:41.29

オブジェクト指向を使うには、変数や関数がある程度以上の個数がないと無意味。
あとインスタンスが２個以上必要な場合じゃないと意味がない。
俺の分野ではどちらも当てはまらないので、オブジェクト指向が活用できない
という結論に至った。みんな、ありがとう。

**デフォルトの名無しさん** · 2014/04/05(土) 21:49:36.29

オブジェクト指向が活用できない分野ってどんな分野よ

**デフォルトの名無しさん** · 2014/04/05(土) 22:16:36.14

書き換えて再利用とか機能の追加が少ない機械みたいな分野だったら
(構造化言語の)Cそのまんまで十分じゃないの、とは思う。

**デフォルトの名無しさん** · 2014/04/06(日) 06:09:18.41

>>212の日本語訳
「俺がいつも書くコードはオブジェクト指向になっていない。
だから俺の分野ではオブジェクト指向は使えない。」

「オブジェクト指向」の部分にどんな技術を入れても成立する
魔法の言い訳だな。

**デフォルトの名無しさん** · 2014/04/06(日) 06:50:21.75

同じものが沢山作れる、ってのは確かにオブジェクト指向のミソだが、
インスタンスが一つだろうと、オブジェクト指向プログラミングによって得られるものは色々あるぞ
再利用性とか、単体テストのしやすさとか、拡張性とかな

あと、オブジェクト指向プログラミングの重要なデザインパターンに「シングルトン」というのがあって、こいつはインスタンスを一つに限定するものなんじゃな
インスタンス一つだから役に立たない、ってのは世の中のプログラマには通じないと思われる

**デフォルトの名無しさん** · 2014/04/06(日) 09:28:19.55

記述側がより人間の思想に近くなったメリットと、実装側でからくり（C++ なら vtable）を生成コードに常に追加するコストとを天秤にかけたら、どっちに軍配があがるかは人それぞれだね
ライナスは OO をぼろくそにけなしているね

**デフォルトの名無しさん** · 2014/04/06(日) 11:55:32.65

>>216
> 再利用性とか、単体テストのしやすさとか、拡張性とかな

単体テストはべつにして、再利用性とか拡張性とか広い意味では複数インスタンスじゃね？

あと、同じものをたくさんじゃなくって、ちょっと違うものを作れるって言うのがミソかと。

**デフォルトの名無しさん** · 2014/04/06(日) 12:55:51.09

>>217
> ライナスは OO をぼろくそにけなしているね
ライナスだけじゃね？ｗ

しかも俺らはカーネル作ってるわけじゃないから、
用途によって言語は変えるべきという正しい考え方からすると、
ライナスが何言っても何使っても関係ないよねｗ

**デフォルトの名無しさん** · 2014/04/06(日) 12:56:37.04

どっちに軍配があがるかは人それぞれというより
用途によりけりってことだろう。

で、大概の用途にOOに軍配が上がると。

**デフォルトの名無しさん** · 2014/04/06(日) 13:06:24.24

ここまでの内容ならライブラリで十分。オブジェクト指向は不要。

**デフォルトの名無しさん** · 2014/04/06(日) 13:16:36.50

ライブラリとオブジェクト指向を同列に語ってる馬鹿は黙ってろよ

**デフォルトの名無しさん** · 2014/04/06(日) 13:29:28.28

こういうのを見ると、やっぱりオブジェクト指向が一般的であることがよく分かるよ。

.NETにおけるSOLID設計原則とデザインパターン
http://www.infoq.com/jp/news/2013/09/solid-principles-revisited

SOLIDとは５つの設計原則の頭字語である。氏の簡潔な説明を借りれば：

単一責務の原則(Single Responsibility Principle)
　　すべてのオブジェクトは唯一の責務を持たなければならない。すなわち，実行することはただひとつでなければならない。

開放/閉鎖の原則(Open-Closed Principle)
　　クラスは拡張に対しては開いて(Open)，修正に対しては閉じて(Close)いなければならない。

Liskovの置換原則(Liskov Substitution Principle)
　　派生クラスは親クラスの置換として使用可能でなければならない。なおかつ，同じ振る舞いをしなければならない。

インターフェイス分離の原則(Interface Segregation Principle)
　　使用しないインターフェースへの依存をクライアントに強制してはならない。

依存関係逆転の原則(Dependency Inversion Principle)
　　具体的な実装よりも抽象に依存するべきである。これはコードの分離に有効だ。

**デフォルトの名無しさん** · 2014/04/06(日) 17:51:43.94

>>223
vtableを生成コードに常に追加するコストに見合うものかどうか疑問だね

**デフォルトの名無しさん** · 2014/04/06(日) 18:19:41.32

vtableの生成コストとか言い出したら、スクリプト言語なんて論外じゃねーかw

**デフォルトの名無しさん** · 2014/04/06(日) 18:34:59.08

C++だとvtableは必要なとこにしか付かないよね

**デフォルトの名無しさん** · 2014/04/06(日) 18:36:50.32

ぷらぷら。ぼくはvirtualなメソッドじゃないよ。

**デフォルトの名無しさん** · 2014/04/06(日) 18:37:51.19

なんでここだけC++初心者スレみたいになってんの？

**デフォルトの名無しさん** · 2014/04/06(日) 18:39:42.35

一番知名度のあるオブジェクト指向プログラミング言語はJavaの筈なのにね

**デフォルトの名無しさん** · 2014/04/06(日) 18:44:04.82

致命度？

**デフォルトの名無しさん** · 2014/04/06(日) 20:38:36.74

いいや、Objective-Cが最後に勝つね

**デフォルトの名無しさん** · 2014/04/06(日) 20:55:17.94

Objective-C++が節操なくて素敵だよw

**デフォルトの名無しさん** · 2014/04/09(水) 01:49:33.61

オブジェクト指向に相対するパラダイムってなによ
関数型＋代数的データ型？

**デフォルトの名無しさん** · 2014/04/09(水) 03:10:51.74

それは相対する、ってほどでも無いような
オブジェクト指向自体も考え方が複数あるからなあ…
関数型はともかく、手続き型でオブジェクト指向に真っ向から相対して組むとすれば

・データと処理がお互いに依存しないように組む、例えば特定のユーザ定義型に依存する処理などは控え、ひとつずつ引数で渡してもらうなどする
・モジュールは流れに沿って切り分ける、例えば全てのデータはデータモジュールに、全ての初期化は初期化モジュールに、本処理はメインモジュールに書く

とか、そんな感じになるのかな

**デフォルトの名無しさん** · 2014/04/09(水) 08:48:53.28

向いてる方向が違うんだから、遠い近いはあるだろうけど相対って言うのはないんじゃね？

**デフォルトの名無しさん** · 2014/04/09(水) 17:51:40.57

>>129
DDD？ってこれパラダイムじゃないか

**デフォルトの名無しさん** · 2014/04/09(水) 18:41:01.22

昔DDDっていうデバッガ使ってたな...

**デフォルトの名無しさん** · 2014/04/09(水) 21:00:52.84

DDT (CP/M-80) じゃなくて？

**デフォルトの名無しさん** · 2014/04/09(水) 21:03:36.40

>>238
gdbのGUIフロントエンドだよ

**デフォルトの名無しさん** · 2014/04/10(木) 22:59:06.71

最近ベクトル演算をする必要が出てきたので、オブジェクト指向のプロパティを
使って実現しようと考えている。

○か×か？

**デフォルトの名無しさん** · 2014/04/10(木) 23:07:48.12

>>240
どう見ても「君には」×

**デフォルトの名無しさん** · 2014/04/10(木) 23:36:09.35

実際にベクトルクラスがあるからそれ参考にする

**デフォルトの名無しさん** · 2014/04/11(金) 02:56:48.62

同じメソッド呼び出しを何度も行うと呼び出しのコードをコピペすることになっ
てしまいます。何もせず名前の意味も不明な多重のメソッド呼び出しはコピペを
防ぐためだったと判明しました。もちろん手打ちしたとのことです。

オブジェクト指向脳っていうんですか？本当に怖いです。

**デフォルトの名無しさん** · 2014/04/11(金) 09:11:53.91

>>243
それ違う。関数脳っていうの（笑）
同じ関数呼び出しを何度も実行すると
関数を何度もコピペすることになるからね（爆笑）

**デフォルトの名無しさん** · 2014/04/11(金) 09:12:29.97

>>243
それ違う。アセンブラ脳っていうの（笑）
同じニーモニック呼び出しを何度も実行すると
ニーモニックを何度もコピペすることになるからね（大爆笑）

**デフォルトの名無しさん** · 2014/04/11(金) 09:13:54.98

>>243
人生で同じ英単語・アルファベットを何度もコピペする略（ゲラゲラ）

**デフォルトの名無しさん** · 2014/04/11(金) 13:07:20.58

なんか面白いんだろうな...
俺には理解できないけど

**デフォルトの名無しさん** · 2014/04/12(土) 12:55:19.47

プログラマはソースのコピペを恐れないでください。誰でも最初は初心者で、
しかも誰もが成長するとは限らないのです。
成長を強いるオブジェクト指向が、万人の解決策になり得ないのは明らかです。
コピペこそが、初心者からベテランまで、万人の解決策となり得るのです。
第一、grepすらできないソースをメンテナンスできるはずありません。

コピペによるプログラミングは、複雑に絡まったバージョン依存問題を解決する
という、潜在的なポテンシャルがあります。

大体、オブジェクト指向を推進する人は、協調性がない人が多く、共同で作業す
るには向いていないのです。冗談のセンスすらありません。

**デフォルトの名無しさん** · 2014/04/12(土) 17:13:54.61

全部反対のことを言っていると見抜けば
>>248が言っていることに納得できるはずｗ

**デフォルトの名無しさん** · 2014/04/12(土) 17:19:09.23

なんか面白いんだろうな...
俺には理解できないけど

**デフォルトの名無しさん** · 2014/04/13(日) 10:45:23.58

ここで僕らは「良いソフト部品は、有名なのだけだ」という原則に立ち戻る必要があるだろうね。
誰も使ってない、メンテナンスもされない俺様オブジェクト部品を使うくらいなら、コピペの方がましな
んだよ。宣言型か関数型が使えるならその方がいいし、使えなければテストの自動化で乗り切る
しかないと、もう１０年も前からいわれて続けているわけだ。
research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.htm

**デフォルトの名無しさん** · 2014/04/13(日) 10:51:49.05

うん、まったくだ。
有名なソフトは良い。

有名じゃなくても良いソフトはまれにあるけど、
多くの、つまり何万、何十万とある無名なソフトはクソでしかない。

**デフォルトの名無しさん** · 2014/04/13(日) 11:22:22.91

ストラウストラップが「オブジェクト指向というのは継承と再利用なんだよ！」ってやったせいで
えらい風評被害やな。

単にクラスというCでの関数に代わる単位の取り回し方法だから
Objective-C辺りじゃ継承…めんどいから使わない
NSObjectってクラスの基本的ふるまいを持った基底クラスから
テキトーなクラス作って、その中に使えるクラスぶち込んで
メッセージ(メソッド)オーバーライドでふるまい変えて使う。
クラスとは単にレゴブロックみたいなパーツ扱い。

**デフォルトの名無しさん** · 2014/04/13(日) 11:38:57.62

＞NSObjectってクラスの基本的ふるまいを持った基底クラスからテキトーなクラス作って
継承してるじゃないの。

むしろC++の方が継承なしのパーツ扱いが多いんじゃないの。

**デフォルトの名無しさん** · 2014/04/13(日) 11:54:36.21

いわゆるObjectクラスが必要な理由って何かあるの？

**デフォルトの名無しさん** · 2014/04/13(日) 12:17:57.96

Objective-Cはとにかくクラスの実体ありきで
言語的にひな型からインスタンスを作るんじゃなくて
起動時に存在するファクトリクラスにallocとinitを送って
クラスに"自分のインスタンスを作らせる"から
すべてのクラスはallocやinit、retainカウント、deallocを受け付け管理する
NSObjectを継承していないとクラスとして存在しえないので…

**デフォルトの名無しさん** · 2014/04/13(日) 15:02:09.06

動的な言語だとだいたいObjectクラスが必須だよね

**デフォルトの名無しさん** · 2014/04/13(日) 15:38:34.94

>>256
別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな

**デフォルトの名無しさん** · 2014/04/13(日) 15:55:24.32

動的な言語でも本来はObjectなんて要らない。
Smalltalk-80だってnilのサブクラスを作れたし。

**デフォルトの名無しさん** · 2014/04/13(日) 16:04:45.61

値の型が動的なのと
変数の型が動的なのとを
区別つけろよ。アホ。

Objectが必要なのは変数に型があって
値の型が動的な場合なだけだ。
変数に型があるが、そこで記述された型だけではなく
互換性がある型を入れられる。
そういう言語でどんな型にも互換性があるのがObject型だ。

変数に型がない言語ではどんな値でも入れられるから
Objectは要らない。変数にはどんな型でも入れられる
とはいうものもコードは互換性がある型を入れてないと
結局正しく動かないんだけどなｗ

**デフォルトの名無しさん** · 2014/04/13(日) 16:17:49.14

値の型が動的ってどういう事？
さっきまでStringだったけど今みたらIntに変わってたわ！みたいな？

**デフォルトの名無しさん** · 2014/04/13(日) 16:24:02.51

変数の型は固定なんだよ。
この変数は、Numeric型みたいに。

でもNumeric型って書いてあっても
その値は実はInt型だったりFloat型だったりと
Numeric型に互換性がある型に変わっていたりする。

変数の型は固定なのに値の型は違う。

それに対して、変数に型が決まってない言語があるの。
変数に型が書いてないなら変数aにどんな型でも入れられる。

**デフォルトの名無しさん** · 2014/04/13(日) 16:26:13.02

Objectって全部に共通の動作を定義するために使われてるよね普通は。
例えば、自分の型を返すとか。

**デフォルトの名無しさん** · 2014/04/13(日) 17:45:48.17

値が型情報持ってない言語は一応あるね、C言語とか
あれは変数側にしか型がない

**デフォルトの名無しさん** · 2014/04/13(日) 18:03:36.88

>>261
SmalltalkではさっきまでByteStringだったオブジェクトが今みたらWideStringだったぜとか普通

**デフォルトの名無しさん** · 2014/04/13(日) 18:07:49.11

>>263
それがルート(基底)クラスだな。
Objective-Cで言えばNSObjectで、全てのクラスのルート。

**デフォルトの名無しさん** · 2014/04/13(日) 18:54:15.96

全部に共通の動作なんてものが必要なうちはダメだな

**デフォルトの名無しさん** · 2014/04/13(日) 19:10:20.98

>>267
ダメな理由書いてみ

**デフォルトの名無しさん** · 2014/04/13(日) 19:31:38.05

>>265
それは参照してるオブジェクトが変わったんじゃないの？

**デフォルトの名無しさん** · 2014/04/13(日) 20:05:02.79

共通の動作がなければ、てんでばらばらって事じゃんw

**デフォルトの名無しさん** · 2014/04/13(日) 20:31:47.78

>>269
Smalltalkではbecome:というメソッドで
ポインタレベルでのオブジェクトの差し替えが可能なんで

| x y |
x := y := 'abc'
x become: 3.14.
y. "=> 3.14 "

これを応用してオブジェクトの型の変更も容易なんですよ

**デフォルトの名無しさん** · 2014/04/13(日) 20:36:46.47

>>259
よく知らないんですけどSmalltalkのnilとObjectって
お互い継承関係にあるんじゃないんですか？

**デフォルトの名無しさん** · 2014/04/13(日) 20:46:56.28

>>271
SmallTalk知らないんだけど、それってxというオブジェクトにbecome:という動作をさせてるの?
そうなら、become:という動作は全オブジェクトに共通だよね。

**デフォルトの名無しさん** · 2014/04/13(日) 20:50:21.03

>>271
Smalltalkよくしらないから適当言語だけど...
x = "x"; y = "y"; z = y;
の状態で
y become: x;
とやったら、
zの指してるオブジェクトは"x"になるって事？

**デフォルトの名無しさん** · 2014/04/13(日) 20:59:39.25

>>268
つ proxyパターン

>>272
nilはクラスではないところがポイント。

>>273
全オブジェクトに共通ではない。

>>274
なる。xが"x"のままの流派と"y"になる流派とがある。

**デフォルトの名無しさん** · 2014/04/13(日) 21:09:17.21

よく知らない三連星ワロタ

>>275
なるほどそういう意図ですか
1. nillはUndefinedObjectのインスタンス
2. UndefinedObjectはObjectの継承している
3. Objectはnilを継承している
こうかな？
となると全てのクラスの共通となる祖先が存在してるんで
不要論として出すのはやっぱおかしくないですか？

**デフォルトの名無しさん** · 2014/04/13(日) 21:15:34.64

知れば知る程Smalltalkのウンコさが身にしみる

**デフォルトの名無しさん** · 2014/04/13(日) 21:40:50.80

proxyパターンと共通の動作にどういう関係があるのかわからん。

**デフォルトの名無しさん** · 2014/04/14(月) 01:52:57.81

>>258
＞別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
いま、C++とかがそこに起因する泥沼に嵌ってるけど
オブジェクトクラスの側は言ってしまえば実装だしライブラリだから
将来に動作を変更されるうるし、実際に変更されるけど
言語仕様はもう一段上のルールだから変更が実に困難だという…

**デフォルトの名無しさん** · 2014/04/14(月) 01:57:18.83

>>259
要らないつうか、それだと基本的なオブジェクトとしてのふるまいを持ってないから
Objective-Cで生のC関数書いたりObjective-C++でC++のクラス扱ってる状態なだけじゃ…

**デフォルトの名無しさん** · 2014/04/14(月) 19:01:11.23

>>276
nilはクラスではないから共通の祖先となるクラスではないよ。
というか基底クラスが複数あるのはそんなに珍しいことではないが、
一体何がわからないのかわからない。

**デフォルトの名無しさん** · 2014/04/14(月) 20:50:15.58

>>281
nilを継承できる事と所謂Object型が不要になる事の繋がりが分からないんですよね
nillオブジェクトとObjectクラスは親子関係にあるのになんでだろう
って思って質問したんです

**デフォルトの名無しさん** · 2014/04/14(月) 21:32:49.46

> 3. Objectはnilを継承している
それが真であれば、Objectはnilの特徴を持っていないといけない。
Objectはnilではないので、これは間違い。

**デフォルトの名無しさん** · 2014/04/14(月) 21:40:20.78

>>280
要らないんじゃなくて、あった方がやり易いってことだよな。
別にObjective-CでもNSObject無視してクラス自作できるけど、まずそんな事しない。

**デフォルトの名無しさん** · 2014/04/14(月) 21:41:56.76

Rubyだと
・nil は Nilクラスの唯一のインスタンス
・NilクラスはObjectクラスから派生したサブクラス

$ irb2.0
irb(main):001:0> nil.class
=> NilClass
irb(main):002:0> NilClass.superclass
=> Object

Smalltalkは知らん

**デフォルトの名無しさん** · 2014/04/14(月) 22:20:14.96

>>283
あ、そうなんですか
Wikipediaに
> 基本的な派生元となるObjectやProtoObjectは、それらから派生したUndefinedObjectのインスタンスオブジェクトであるnilを継承しており再帰関係を持つ。
と書いてあったんでそういうものだと思ってました
あと
Object isKindOf: nill
が true を返すのはなんででしょう？

**デフォルトの名無しさん** · 2014/04/15(火) 04:06:44.72

>>285
つまりnilとNilは別々のオブジェクトであり、
NilがObjectのサブクラスであることとnilは何の関係もない、
ということだね。

>>286
つまりnilとUndefinedObjectは別々のオブジェクトであり、
UndefinedObjectがObjectのサブクラスであることとnilは何の関係もないし、
nilはクラスではないし
Squeak4.4ではObject isKindOf: nilはfalseだし、
Object new isKindOf: nilもfalseだし、
仮にtrueになる処理系があっても、nilはクラスではないからnilはObjectの基底クラスではない、
ということだね。

**デフォルトの名無しさん** · 2014/04/15(火) 18:46:18.65

>>287
ありしゃす、Object isKindOf: nil の結果は実装依存なんですね
true になるのはGNU Smalltalkでした

**デフォルトの名無しさん** · 2014/04/15(火) 20:46:27.61

>>287
>つまりnilとNilは別々のオブジェクトであり、

nil はインスタンスでありNil はクラスだから、別々のオブジェクトってこと

>NilがObjectのサブクラスであることとnilは何の関係もない、

Nil と Object とは「サブクラス-スーパークラス」という継承関係であり、
Nil と nil とは「クラス-インスタンス」というインスタンス化関係であり、
二種類の関係をごっちゃにしてはいけない、ってこと

**デフォルトの名無しさん** · 2014/04/15(火) 21:07:45.24

>>286
>> 基本的な派生元となるObjectやProtoObjectは、
>>それらから派生したUndefinedObjectのインスタンスオブジェクトである
>>nilを継承しており再帰関係を持つ。

Rubyの場合
・ClassクラスのスーパークラスはModuleクラスである（継承関係）
・ModuleクラスのスーパークラスはObjectクラスである（継承関係）
・ObjectクラスはClassクラスをインスタンス化したオブジェクトである（インスタンス化関係）

$ irb2.0
irb(main):001:0> Class.superclass
=> Module
irb(main):002:0> Module.superclass
=> Object
irb(main):003:0> Object.kind_of?(Class)
=> true

結果として、各クラス間の関係は「循環的」に定義されることになる
ただしRubyコミュニティでは、それを(その循環関係)を「再帰的」と呼ぶ事はない

Smalltalkは知らんけど、おそらく、そのWikipediaの著者が
継承とインスタンス化をごっちゃに理解しているんじゃないかと思われ

**デフォルトの名無しさん** · 2014/04/15(火) 21:25:46.27

>>288
GNU Smalltalk は名前から受ける印象と違って
単なるファンお手製の勝手実装なうえに、
Smalltalk としてもかなりの変わり種なので
あれを元に Smalltalk がどういうものか学ぶのはちょっと問題が。
できれば VisualWorks 、悪くても Squeak/Pharo で
試すようにするのがよいと思います。
（これらの処理系はそれぞれ独自の進化を遂げてはいますが、
いちおう古典的 XEROX Smalltalk-80 からの直系の派生物で、
その名残を多く残しています）