vieweditattachhistoryswikistopchangessearchhelp

メッセージ送信

オブジェクトに対してメッセージを送信すると、受信したオブジェクトが対応するメソッドを起動する。--SHIMADA


関連：
--sumim


オブジェクト指向プログラミング、あるいはオブジェクト指向言語が機能として備えその実現をサポートすべきもののひとつとして挙げられる「多態性」を表すために使用されることもある。--sumim


オブジェクト指向プログラミングとメッセージ送信メタファに関するメモ--sumim

結論として、メッセージ送信メタファは、「オブジェクト指向」の説明おいて“必ずしも適切かつ必要不可欠であると限らない”ということを念頭に置きつつ用いなればならない、ということは確か。--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

External Image
意味無く、絵など描いて遊んでみました…。
これ（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

うーん。そのせいで我々は病気を治療し難いのだと思うんですが(ぉ
つまり、(刹那的な)関連が、把握しきれないほど多くて複雑なんです。

生物並のアレを実際サポート出来ているというなら、それはそれなんですが、
サポート出来もしないのに自由度だけ与えられても、アセンブラ与えられたような気分にしかならないです。

ほら、生物についてだって、例えば「血管」なら、我々は近年
それを結構自在に修理する術を身に付けてるわけです。
一方、人工肝臓はまだまだ夢。

プログラムも同じようなものじゃないか？と思うんでうｓ。

扱いきれる範囲の数の配線で済む問題は、難しい刹那通信方式じゃなく、配線方式で済ますほうが、楽じゃないかなあ？
せっかくソフトウェアでは、世界を我々が規定できるんですから。

なお、配線が柔軟性を「損ねる」わけじゃないです。
プログラムが配線を切り替える権利を一切認めないつもりは(俺は)有りませんので。--戯

配線をプログラムが自由にできるとなると、やはりソフトウェア配線の引用でアラン・ケイが言及している
メタシステム、メタプログラミングの世界が有力なのでしょうかね。--sumim

配線を変える「くらい」でメタって呼ぶことは無いと思ってます。
回路の世界にもリレーやトランジスタは有り触れた素子として存在してるし。 --戯


このページを編集 (16804 bytes)

Congratulations! 以下の 12 ページから参照されています。

This page has been visited 9241 times.