メッセージ送信
オブジェクトに対してメッセージを送信すると、受信したオブジェクトが対応するメソッドを起動する。--SHIMADA
関連:
- [はてな]「オブジェクト指向の概念の発明者は誰ですか?」
- メッセージ送信の比較
C++、Java、Objective-C、Smalltalk、Dylan、Ruby、SELF、Perl の比較。
--sumim
オブジェクト指向プログラミング、あるいはオブジェクト指向言語が機能として備えその実現をサポートすべきもののひとつとして挙げられる「多態性」を表すために使用されることもある。--sumim
オブジェクト指向プログラミングとメッセージ送信メタファに関するメモ--sumim
- Algol 系の文法を踏襲している言語には「メッセージ」というメタファや呼び名は馴染まない。
- 少なくともその見た目は単なる(あるいはちょっと変わった)関数呼び出しにすぎない。
- Smalltalk タイプの文法におけるメッセージには、Algol 系関数名では表現しにくい情報も盛り込める。
- よく考えられたメッセージは意味するところを際だたせ、コメントの必要性を軽減する。
- 設計ももちろん大切だが、適切な命名はもっと大切で Smalltalk タイプの文法ではその効果も絶大である。
- しかし、文法は所詮見た目に過ぎず、メッセージ送信は実質的にも“「関数」呼び出し”としてよいとの意見もある。
- ここで 「関数」は次のようなものを想定しているらしい。
- 別の処理への(必要なら)パラメータを伴う移動
- 終了後に(必要なら)結果を伴って戻ってくる
- アクター理論に基づくオブジェクト指向言語のメッセージは、非同期なので 2. の条件を満たさず「関数」ではないらしい。
- したがって、Concurrent Smalltalk でもなければメッセージと呼ぶにはふさわしくない、という。
- しかし、メッセージは「オブジェクト メッセージ」文法とセットでアラン・ケイが用いたメタファ。
- アクター理論は、このアイデアを(文法と切り離し)取り込みつつほどなくして体系づけられたもの。
- オブジェクト指向のメッセージがアクター理論由来という説明は(完全には)あたらない。
- ほぼ同時期なので互いに影響を及ぼしあった可能性があるから。
- ヒューイットが必要以上に謙虚だったのでもないかぎり、Smalltalk → アクター理論の順に間違いはない。
- しかし、文法とメタファに関する論文をアラン・ケイは当時、まとめていないので学術的には通じない。
- アクター理論に“照らす”必要性がなければ、Smalltalk におけるメッセージの存在を否定する意見はあたらない。
- Smalltalk の文法は、オブジェクト指向におけるメッセージ送信というメタファと不可分な関わりを持つ。
- Smalltalk(あるいはその文法に倣った言語)を想定した場合、メッセージというメタファは効果を発揮する。
- Self は self の省略を推奨し、メッセージを関数的に用いようとする傾向があるので意味、失格(^_^;)。
- 本件とは関係ないが、しかし、クラスを用いない Self のオブジェクトモデルは理解しやすく秀逸。
- 逆に、Algol 系文法の言語からメッセージメタファを実感するのは、置き換えが必要ですんなりは行かないはず。
- あらかじめ、メッセージ送信メタファを用いた「オブジェクト指向」ができていればその限りではない。
- ストラウストラップはメッセージというメタファは使っていない、らしい。
- 「カプセル化」「継承」「多態性」の基本三要素は C++ で体系づけられた、らしい。
- 「カプセル化」が Smalltalk に必ずしも馴染まない「情報隠蔽」を意味するようになったのもこうした背景?
- この三要素を際だたせた Smalltalk のオリジナル論文は見つからない。
- 現在用いられている「オブジェクト指向」に対する説明は、C++ と Smalltalk の世界観を融合(混同)したもの。
- Smalltalk には Simula 時代に戻る「クラス指向」に偏った説明に見える。
- C++ にはメッセージという馴染まない概念を強要される。
- かつての参考書にはメッセージを用いる際 、Smalltalk への言及が必ずあったが、現在は省略されるのが普通。
- Smalltalk はもはや、数あるオブジェクト指向言語のひとつに過ぎないとのコンセンサスがほぼ成立。
- 別格扱いは無用、不愉快。意味無く変な文法。注目に値しないがゆえのマイナー。Smalltalk 厨、などなど。
- メッセージは一般にアクター理論から、ということになっている。
- メソッドが Smalltalk 由来の用語であることを知らない Java ユーザーも多い。
- メソッドは、C++ ではメンバ関数がそれに相当する。が、Java の影響でメソッドと呼ばれることも多い。
- メソッドはもはや Java 発祥の用語?
- メッセージとメソッドを混同、あるいは混用するのは Algol 系文法である以上やむを得ない。
- メッセージとセレクタを同一視してしまう Smalltalk、Objective-C ユーザーもいる。これも関係あるかも。
- セレクタは関数名に相当し、メッセージはいわば関数名と引数の組。したがってセレクタこそ…となる。
結論として、メッセージ送信メタファは、「オブジェクト指向」の説明おいて“必ずしも適切かつ必要不可欠であると限らない”ということを念頭に置きつつ用いなればならない、ということは確か。--sumim
あちこち(?)での議論を少し見たけど、どうも違和感が。 -戯
メッセージ送信って、単に「オブジェクトに(なんらかの形でなにかを)お願いする」ことでしかない、と思ってたんで。
その意味では、曲りなり(?)にもOOPを標榜する言語ならどれでも(C++ですら)、
オブジェクトになんかを依頼する仕組は「メッセージ送信」と呼んでいい、んでねーの?としか思ってない。
少なくとも、メッセージ→コンカレントという「語感」を抱く人の意見については、
俺はそんな「語感」は感じません、としか答えようが無い(^^;し、
文法の問題は明らか(俺にはね)にメッセージかどうかの問題とは独立な問題だろうし。
それぞれの言語においてMessageが(First Class)Objectであるかどうかは、また別問題だという気がするし。
#もちろんそうなってるほうが嬉しいが…
#仕組が有るのは恐らく明らかなのに、ただそのAPIが「公開」されてないためだけにMessage Object的なものが使えない、という処理系で苦しんでます(^^;
C++とかでの「関数っていう立派な名が既に有るじゃん」という意見に対しては、
「OOPと大して関係ない文脈では、まあそんなもんだろな。
OOP的にモノを考えるときには、メッセージって言いたきゃ言ってもいいんじゃない?」ってなとこ
まあマイナーな言語も含めれば、皆さんの議論(=思考)に全然登らないような無数の有象無象な
「メッセージ」のような(あるいは人によってはメッセージだと思えないような)かたちが有るわけで。
…って話ではなく??
そうですね。
無難にまとめれば、
世の中には「オブジェクトへのメッセージ送信」というメタファは、
自分の考える「オブジェクト指向」の中にない、という人もいることを忘れちゃいかん…
って程度の話です。
逆に、まあ莫迦みたいなことを言うようですが、
現在メジャーな「オブジェクト指向」言語は、
“オブジェクト指向”で作られた環境で使え、
ユーザーが“オブジェクト指向”したものをそのままメッセージ式に書き下せる Smalltalk 以外、
“純粋”はおろか、“オブジェクト指向”を名乗ることすらおこがましいって
(厨にありがちな(^_^;))話でもあるわけなんですが…。
ここで「オブジェクト指向」は一般的に認知されているオブジェクト指向で、
いうなれば「クラス指向」のようなものを、
“オブジェクト指向”はオブジェクトへのメッセージ送信による問題解決の手法を想定しています。--sumim
もう少し言うと、
今のオブジェクト指向言語は(ここはあえて Smalltalk を含めて)
我々の 私の“オブジェクト指向”を
サポートするにはまだ足りない(し、それを使うのに知らなければならない余計なものが多すぎる)
…というと語弊が少ない、かも。--sumim
ところで、未だに判ってないっていうか、これ言ったら堂堂巡りになりそうな予感もするんですが、
>ユーザーが“オブジェクト指向”したものをそのままメッセージ式に書き下せる Smalltalk
Smalltalkのあれをメッセージ式と呼び、一方でJavaやC++のあれをメッセージ式とは呼ばない、のは何故なんでしょうか?
単なる字面の相違にしか思えないのですが…?
だって、C++っぽい文法だけど内部的に完全にSmalltalk的な挙動をしてくれる言語(&処理系)を作ることは可能だよね?
#どこかからRubyという声が聞こえてくる…(藁 -戯
#ごめんなさい。「書き込み」のヘルプって何処でしたっけ?特に、自分の「書き込み」を周囲と違う「色」にするワザは、どうするんでしたっけ?
>自分の「書き込み」を周囲と違う「色」にするワザ
書き込みボックスからだけ利用可能な機能で、「--シグネチャ%red」などと最後にします。
タブルハイフンとパーセント+ウェブカラー名が味噌です。
ウェブカラー名を短縮すると頭からマッチしたカラーが採用されます。
たとえば、--戯%g は green になります。なるはずです(^_^;)。
え〜と、短縮については ここら へんで昔、テストしましたので参考にしてください。
あ、%g で green になるみたいですね。
なお、書き込み前後の改行は無視されるので改行の挿入は自由です。
ある種、隠し機能(^_^;)ってか自分専用機能なんでヘルプには書いていません。ごめんなさい。--sumim
>C++っぽい文法だけど内部的に完全にSmalltalk的な挙動をしてくれる言語
そう、そこなんですよ。この感覚の違い。なんと説明したらいいか…。
メッセージの表記として
「func(arg1, arg2, arg3)」ではやはり駄目で、
「do: something for: me」形式がメッセージと呼べるぎりぎり限界かなぁ…と。
たしかにこれは「doFor(something, me)」と理論的には一緒なんですけどね。
私の“オブジェクト指向プログラミング”としては「doFor(…」をメッセージ表記と呼ぶにはつらすぎるんです。--sumim
ところで、
do: something for: me が、doFor(something, me) と理屈上、同じなのと同じくらい
doFor(something, me) は (do-for something me) と同じと思うのですが、
これで間違いないでしょうか?--sumim
意味無く、絵など描いて遊んでみました…。
これ(SqueakLand.org 版 Squeak )をインストールしておくと、
クリックしてウェブブラウザ内で、そのまま編集できます。(ただし、限られた OS の一部のブラウザのみ)
編集はできるのですが、編集したあと、リンクを張り直さなければならないのが面倒です(爆。--sumim
(do something :for me)とする手もあります。キーワード引数は省略可能なオプショナル引数ですから do:for: でひとつのセレクタと考えると全く等価とはいえませんが。--SHIMADA
キーワード、キーワード引数という概念が Lisp/Scheme にあるのは知りませんでした。
たしかに等価ではありませんが、ずいぶんと読み下し(書き下ろし)やすくなりますね。
本題からそれるのですが、これはかなり初期の Lisp から装備されていた機能(概念)なのでしょうか?
だとすると、Smalltalk のキーワードメッセージという(ある意味、誤解を招く(^_^;))呼び名や“:”の由来はこれかな…、と。--sumim
「名前つき引数」と、「(C++みたいな)メソッドのシグネチャでオーバーロードする」のとを
組み合わせると(というか、もしそんな言語が有れば)、割と似た感じになるんじゃないかな?
hoge.send({:do=>something, :for=>me})
# rubyもどきの文法で書いたと思いねぇ。名前つき引数はHashで渡す感じ。
とかさ。 --戯
ふつーのシグネチャオーバーロードは、引数の型と数で判別するもんだけど、
この場合はそうじゃなく引数の名でやるってことになる。
#ところで色つき署名のバグらしきもの発見。署名より後にも文章が続くと、それが消えちゃいました。文の途中に署名書くのは悪徳じゃないよねえ?
悪徳ではないですが、仕様です(^_^;)。ちょっとくどくなりますが、最後にもシグネチャを付けて回避してください。--sumim
>(do something :for me)とする手もあります。
ただ、S 式のキーワード引数を使った場合でも(do:for: と同義でないことを譲っても)
両端の括弧は残ったままだということはついつい忘れがちですが結構重要です
(リスパー脳になるとこの括弧は不思議と消えて見えなくなるのですが(笑))。
>割と似た感じになるんじゃないかな?
ご呈示いただいた例もしかりで、おっしゃるとおり、それで似たこと(語順の調整)はできます。
ただ、語順が適切か、ということもたしかに大事なことなのですが、それだけでは駄目で
括弧など余計な要素にわずらわされることなく、“誰にどんなメッセージを送るか”という思いつきを、
そのまま素直に書き下せるか(あるいは、読んだときにそのまま読めるか)ということも
配慮されるべきではないかとここでは考えています。ので…、
残念ですが、これらの記法を“素直”と呼ぶには無理があるのではないかなぁ…と。
逆にそうしたものをすんなり書き下せる人は、do_for(something, me) 、
あるいは (do-for something me) の脳内置換で十分でしょう(^_^;)。
“:”を付けたり、キャピタルレターにする(逆に括弧やスペース、カンマを自由に入れられない)という
パーサーに優しい落としどころがある Smalltalk の式も、もちろん、完璧とはいえません。
しかし、それだけで済んでいる Smalltalk の式は非常によく考えられているんじゃないかなぁ…、
ひいては、これを「メッセージ式」と呼んで別格扱いしてもバチはあたらんのじゃないかなぁ…と思う次第なわけです。
脳内パーサーを持つ人や、
Algol 系プログラミングに長年、慣れ親しんできた人には
メッセージ式を特別扱いする理由も
それが必要とされる理由も理解できないのは重々承知の助です。
要は慣れの問題、脳の適性の問題、というだけなのかもしれませんね。
ただコミュニケーションを重視する“オブジェクト指向”に徹するのなら、
実装時に使う文法もコミュニケーション手段のひとつと考え、
配慮するに足るファクターと捉えるべきだという問題意識は持ち続けたいと思っています。--sumim
まあ、そんなことを言ったところで自分で新しい言語のひとつも作らな
しょうがないんですけどね…(^_^;)。--sumim
うーん。ところでドリトルはいかが? --戯
ん〜、どうでしょう。一見、いいセンいっているようですが、
引数を単に列記して最後にコマンド(従来の関数名)で締めているだけような気も…。
ちょっと、サンプルプログラムに目を通してみます。
この文法でも、どんなオブジェクトにいかなるメッセージを送信しているかすんなり頭に入ってくるようなら、
私も考えを変えないといけないかも…(^_^;)。--sumim
ざっと見てみましたが…、
条件文もメッセージ送信なのは“オブジェクト指向”実践の徒として好感が持てますね。
自身を指す偽変数がないのや、レシーバが自身のとき省略で代替えさせるのは Self 言語同様残念です。
メッセージ送信がすんなりイメージできるか、という点については…未知数ですね。
タートルに特化されたコードが多いので(^_^;)。
こういう用途に限るなら、これでいいようにも思います。--sumim
>両端の括弧は残ったままだということはついつい忘れがちですが結構重要です
>(リスパー脳になるとこの括弧は不思議と消えて見えなくなるのですが(笑))。
オレもリスパー脳だったのか。 ( ・∀・)つ〃∩ ヘェーヘェーヘェー --SHIMADA
SHIMADA さんは、消えるクチ? > S 式の括弧 それとも反語的に?--sumim
SICP読んでるうちにだんだん霞んできました。--SHIMADA
要求に対してどう応答させられるか?を、要求(つまり呼び出し名)自体が決定するわけではなく、「こっち」の事情も加味して決定する、
っていうのが、ここらへんで言ってるメッセージの意味合いだったりしないかな?
本音と建前(藁)の分離。
で、「こっち」に相当するものが、オブジェクト指向ならオブジェクト(やその決定権委譲先であるプロトやクラス)だし、
他のナンタラ指向ではカンタラだ、ということなんじゃないかな?#実在するかどうかは俺は知らないが。
で、多態つーかvirtual(C++用語ならば)が、それを実現するための肝な道具だ、ということかと。 --戯
きっとそうでしょう。
ダン・インガルスも初期のオブジェクト指向でそんな説明をしています。
ファンクション指向ではなく、オブジェクト指向だと。
これをメッセージ中に含まれるパラメータの都合も合わせて考えるようになると
総称関数とかになるんでしょうね。
ただこうなると、オブジェクト指向をなにか超越してしまっているように思えますが。--sumim
あと、アラン・ケイのメッセージ送信メタファというのは、
ソフトウェア配線にあるような、IC と 配線のメタファのようなリジッドなものではなく、
多細胞生物における細胞間通信、あるいは、細胞内小器官間通信のような比較的柔軟なものをイメージして作られたようです。
もちろんその域を目指したと言うには、Smalltalk はあまりに初期の段階でその進化をとめてしまっているわけですが。--sumim
うーん。そのせいで我々は病気を治療し難いのだと思うんですが(ぉ
つまり、(刹那的な)関連が、把握しきれないほど多くて複雑なんです。
生物並のアレを実際サポート出来ているというなら、それはそれなんですが、
サポート出来もしないのに自由度だけ与えられても、アセンブラ与えられたような気分にしかならないです。
ほら、生物についてだって、例えば「血管」なら、我々は近年
それを結構自在に修理する術を身に付けてるわけです。
一方、人工肝臓はまだまだ夢。
プログラムも同じようなものじゃないか?と思うんでうs。
扱いきれる範囲の数の配線で済む問題は、難しい刹那通信方式じゃなく、配線方式で済ますほうが、楽じゃないかなあ?
せっかくソフトウェアでは、世界を我々が規定できるんですから。
なお、配線が柔軟性を「損ねる」わけじゃないです。
プログラムが配線を切り替える権利を一切認めないつもりは(俺は)有りませんので。--戯
配線をプログラムが自由にできるとなると、やはりソフトウェア配線の引用でアラン・ケイが言及している
メタシステム、メタプログラミングの世界が有力なのでしょうかね。--sumim
配線を変える「くらい」でメタって呼ぶことは無いと思ってます。
回路の世界にもリレーやトランジスタは有り触れた素子として存在してるし。 --戯
このページを編集 (16804 bytes)
|
以下の 12 ページから参照されています。 |
- Smalltalk 最終更新: 2007-02-13, 17:54:17 <pharm88>
- HyperCard 最終更新: 2003-09-29, 00:25:22 <192>
- プロトタイプベース・オブジェクト指向 最終更新: 2006-04-26, 10:32:39 <khp0591>
- ドリトル 最終更新: 2004-10-28, 19:47:06 <tibook>
- Smalltalk の学びにくさの原因 最終更新: 2004-07-07, 00:55:41 <osk3-p3>
- Object感覚の学びにくさの原因 最終更新: 2004-08-31, 14:04:48 <apollon>
- HyperTalkとプロトタイプベース 最終更新: 2004-12-04, 16:46:06 <adsl-22>
- メソッド 最終更新: 2003-10-03, 21:17:04 <laplace>
- メッセージ 最終更新: 2003-10-03, 21:16:32 <laplace>
- Chain of Responsibility 最終更新: 2004-11-11, 16:13:41 <ns>
- ソフトウェア配線 最終更新: 2005-01-20, 11:45:54 <61>
- 個々の書き込みの見分けをよくする工夫について 最終更新: 2003-11-06, 02:47:32 <airh128>
This page has been visited 9248 times.