MOSA Multi-OS Software Artists

MOSA Developer News［MOSADeN＝モサ伝］第139号

2004-12-07

目次

• 「特定非営利活動法人MOSA」設立にあたって　　 MOSA会長　矢野 孝一
• SqueakではじめるSmalltalk入門　　　第21回　　鷲見 正人
• 藤本裕之のプログラミング夜話　#58
• 高橋真人の「プログラミング指南」　 第57回
• ニュース・解説

「特定非営利活動法人MOSA」設立にあたって

　任意団体としてのスタートから10年。11年目の今年、NPO法人として新たなスタートをする事は、まさに大きな節目となりました。
　我々を取り巻く環境も10年前とは大きく変わり、オープンソースの潮流が益々拡大しております。我々の活動も、そうした新たな動向に沿いながらさらに充実、発展して行くことを願っています。
　会員の皆様や協賛企業の方々のご理解とご協力により、MOSAの活動が今まで以上に活性化していきます様、理事一同努力して参りますので、宜しくお願いいたします。

　　　　　　　　2004年12月　　特定非営利活動法人MOSA　会長　矢野 孝一

設立総会／懇親会開催のご報告

　2004年12月1日からのNPO法人活動開始にあたり、12月3日（金）、東京都目黒の「東京都庭園美術館大ホール」におきまして、「特定非営利活動法人MOSA
　設立総会／懇親会」を開催いたしました。

　当日は66名が参加、設立総会も無事終了し、懇親会においてはアップルコンピュータ株式会社　代表取締役　兼　米国Appleマーケティング担当バイスプレジデント前刀禎明氏、社団法人日本コンピュータシステム販売店協会　専務理事　弓削芳光氏よりご祝辞を頂戴しました。
　また、株式会社アクト・ツー、アップルコンピュータ株式会社、マイクロソフト株式会社、マイクロソフト プロダクト デベロップメント リミテッド各社よりお花をお贈りいただきました。
　まずは、この場をお借りして厚く御礼申し上げます。
　設立総会／懇親会の模様は、こちらに掲載しております。
http://www.mosa.gr.jp/?p=147
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　MOSA事務局

SqueakではじめるSmalltalk入門　　　第21回　　鷲見 正人

　本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。今回はオブジェクト指向の“種類”と継承の関係についてです。

継承とは、端的には、定義済みのクラスからの差分を記述するだけで、新しいクラスを定義できるようにするための“端折り”目的の機構です。ただその位置づけや意味は、その処理系が拠り所とするオブジェクト指向が「何を重要視するか」により様々です。たとえば、古くからのMacユーザーにはお馴染みのHyperCard（HyperTalk）ではイベントの伝達系路、あるいは「委譲」の意味を持たせていたり、C++の流れを汲む静的型チェックを行なう言語では多態性を実現するための「派生型（サブタイプ）」定義に欠かせない機構であったりします。

人によっては「定義など存在しない」とまで言い切る“オブジェクト指向”ですが、私が調べたところでは、そのオリジンはかなりはっきりしていて、ほぼ2つに絞ることができます。ひとつは、アラン・ケイが最初に「オブジェクト指向」という言葉を作ったときに想定していた意味合いで、「メッセージ指向」【註1】と呼ぶべき考え方です。もうひとつは、C++の設計者であるビアルネ・ストラウストラップが1980年代半ば頃までにまとめた「継承によるプログラミング」と称されるものです。

ケイのメッセージ指向は、簡単には、「パーソナル・コンピューティングに関わるすべてを“オブジェクト”とそれへの“メッセージ送信”で表現すべし」というドグマにより成り立たせようとする世界観で、哲学的には、ライプニッツのモナド論に通じるところがあります。また生物学的には、すべてが細胞（あるいは機能性タンパク質）で成り立ち、その間でのシグナル授受で営まれる多細胞生物の活動の様子をヒントに、それをシステムソフトウエアへ応用したものとも言われています。Smalltalkは、この「メッセージ指向」を1970年当時の技術で実践し、その有効性を実証するために作られたシステムだと考えることもできます。

他方で、ストラウストラップの考え方は「メッセージ指向」とはまったく別の独自のアプローチで、C++の仕様策定と実装を通じて整理されました。これは、ユーザー定義型による抽象化手法（抽象データ型）に、継承と仮想関数の動的結合を組み合わせたもので、オブジェクト指向の定番三要素である「カプセル化（抽象データ型、情報隠蔽とも）」「継承」「多態性（多相性、動的結合とも）」の元になった考え方です。ポイントは、SIMULAという言語で初めて言語機能として備えられた「クラス」【註2】を、ユーザー定義型、つまり抽象データ型に見立て、その継承機構を型の派生（サブタイピング）に流用するところにあります。クラス中心の考え方なので、個人的には簡単のため「クラス指向」と呼ぶことにしています。

「オブジェクト指向」の名の下に、両者は渾然一体として語られがちで、それゆえにオブジェクト指向という考え方は非常に分かりにくいものになってしまっていることは、皆さん、すでにご存じのとおりです。長い歴史の中で繰り返されてきたオブジェクト指向言語間論争のようなものも、根は両者の混同にあると言って過言ではないでしょう。たとえば“純粋なオブジェクト指向”では「すべてがオブジェクトでなければならない」からC++やJavaはてんで駄目だ…とか、Smalltalkで既存のクラスのソースが公開されていたり、それを動的に変更できるのはオブジェクト指向の原則である“情報隠蔽”に反する…などといった類はその典型です。クラス指向において、ユーザー定義型が基本型と区別なく扱えるようになっているべきではありますが、すべてがユーザー定義型である必要はありません。また、オブジェクトそれ自体よりメッセージングのほうに重きを置くメッセージ指向においては、C++などのクラス指向で言うところの「データ型としての完全さ、安全性」にはあまり力は注がれてはいません。

継承についても同じようなことが言えます。データ型というものを拠り所として物事の抽象化を行なおうとするクラス指向においては、派生型を作るために使われる継承機構というものはたいへん重要な役割を担っています。仮想関数（派生型により再定義されることが期待されるメンバー関数）による動的結合、つまり“多態性”も、継承機構あっての話です。もっとも、クラスとその継承機構を、データ型とその派生に流用することには、理屈の上では問題があることがウィリアム・クック【註3】によって証明されていたり、現場でも継承はトラブルを起こしがちであることが分かってきているなど、クラス指向の屋台骨である継承の地位は現在、急速下降気味だったりもしますが、それはまた別のお話。

一方で、メッセージ指向を拠り所とするSmalltalkにおいて継承は、クラス指向をあえて意識しないかぎり【註4】、冒頭で述べたように、既存のリソースの再利用のために用意された便利な機構に過ぎません。たとえば静的型チェックを行なわないSmalltalkにおいては多態性も、継承を用いずとも実現可能です。さらには、継承が引き起こす型安全性を壊す深刻な問題などともまったくの無縁でいられます。そんなわけで、継承については当面「使えるときに好きに使う」程度のものと考えておけばよさそうです。

Smalltalkでは、既存のクラスを継承して生じるクラスのことを「サブクラス」と言い、相対的に、継承の元となるクラスを「スーパークラス」と呼びます。引き続き、BankAccountのサブクラスとしてStockAccountを定義し、株式口座オブジェクトを作ってみましょう。

註1：ケイらは、1970年代前半までは実際に、彼らの“オブジェクト指向”を意味する局面で「メッセージ指向」という言葉を使っていました。

註2：「クラス」と「オブジェクト」は、シミュレーション用言語であったSIMULA-Iにおいて「アクション」と「プロセス」と呼ばれていた言語機能を、汎用言語のSIMULA-67（のちにSIMULA）にバージョンアップする際に言い換えたのがその始まりです。「疑似並列処理」のための機構でした。このSIMULAの「クラス」and/or「オブジェクト」という言語機能をヒントにして、抽象データ型（ユーザー定義型による抽象化手法）に加え、クラス指向やメッセージ指向などのオブジェクト指向といった新しいパラダイムが生まれたわけです。

註3：継承とサブタイピングの関係の研究に詳しいウィリアム・クックは、AppleScriptの主要開発メンバーとして、実は、我々Macユーザーと大変関係の深い人物でもあります。

註4：Smalltalkでも、制限付きながらクラス指向を実践することは可能です。むしろ、メッセージ指向と衝突したり矛盾しない範囲であれば、クラス指向のエッセンスを汲んだ設計が強く推奨されるのが普通です。

バックナンバー：
http://squab.no-ip.com:8080/mosaren/

藤本裕之のプログラミング夜話　#58

　承前、カッコの話である。前回はカッコが多くなるとプログラムが見にくいという意見に対して、それはカッコの書き方が悪いだけでありチットもカッコのせいではない、という話をした。今回はもそっと話を掘り下げて、そもそもカッコとはなんであるかという哲学的考察からコトをはじめたい。

おっと本稿読者中にまさか、なんで数学ならまだしも哲学なのだ、あほかコイツはなどとウソぶく浅学非才の徒はおられぬと思うが、一応解説をしておくと数学だの論理学だの天文学だのという学問がそういう風に分類されたのは高等教育というものの方法が確立した近代以降の話であって、かのピュタゴラスは自分を「数学者」だなんてこれっぽっちも思っていなかったし、ゼロを発見した名もなきインド人に至ってはおそらくは「学者」とさえ自称していなかったに違いないのだ。
　そしてオレがこれからここで解説を試みようとしている内容は、それこそゼロの発見ほどまで古くはなかろうがピュタゴラスにとっては既に自明のことであったに違いないことがら。つまりこれら全ての考察が「真理の探求（philosophia）」と呼ばれていたことのコトであるので、その日本語訳……ちなみに翻訳は西周（にし・あまね）先生である、を採って「哲学的」と申し上げているものである。

　余談おわり。再度問う。そもそもカッコとはなんであるか。
　「ゆとり教育」とかが始まってとにかく日本の子供は日の丸見上げて元気に君が代歌っていればいいんだ、となる以前の小学校の算数では、このカッコを四則演算の優先順位を自在に変動させるものとして初めて習う。すなわち「4 + 5 x 6」の答えと「( 4 + 5 ) x 6」の答えは違うというヤツである。覚えがあるでしょ？
　そのせいか、書式は多々あれど同様に四則演算を行なうプログラミング言語の理解においてもカッコをそのようにしか認識していないヒトが少なからずいらっしゃる。が、カッコによって演算の優先順位が変わるのはカッコを使用した結果であってカッコ使用の目的ではないのだ。ここをハキ違えるとカッコの本質を見失ってしまう。
　再度、今度はもそっと一般化してカッコなしとカッコありの2つの式を並べてみよう（Cなど多くのプログラミング言語で使う乗算演算子は「*」だが、ここでは算数に戻って考えていただくべく「x」を使っている。「x」は文字の「エックス」ではないので揚げ足取りはしないでいただきたい）。

　a + b x c ——- (1)
　( a + b ) x c —- (2)
　( a + b x c ) —- (3)

　(2)の式におけるカッコの意味を「カッコが無い場合の優先順位を変更し、cとの乗算より先に a と b の加算を行なう」と考えるヒトにとって、(3) の式で使われているカッコは何の意味も無いただの飾りである。まぁ小学生の算数ではその理解でも問題はないが、中学生になって代数が入って来るとモノの本質がおぼろげに見えて来る。

　a + 1 ————- (4)
　2( a + 1 ) ——— (5)
　3( a + 1 ) ——— (6)

　勘の鋭いヒトはもうお気づきだろうが、(4) の式は実はこうも書ける。

　1( a + 1 ) ——— (4′)

　整数 1 との乗算はその対象を変化させないから、我々は特例として (4′)を(4)と書いている。または整数 1 以外との乗算はその対象を変化させてしまうので、我々はそれを正しく表現するために (5) あるいは (6) のようにカッコを使っている、と言っても同じことだが、正規化すれば (4′) こそがこの式の基本形であり(4) の方が便宜型だと言って多くのプログラマ諸氏に納得していただけるのではないかと思う。

もう紙幅がないので今回は結論として、カッコの正確な意味だけ書いてここで終える。カッコとはとりもなおさず「その内包する部分をその外側から隔離して評価するという意味の表現」である。 小学生が「カッコの中を先に計算しなさい」と教わるのは、そうしないとその外側の値に内側が干渉されることになるからなのだ。そして次回以降に観るように、これは我々が禄を食むところのプログラミングにおいて必要不可欠の重大な概念なのである。では以下次回。
（2004_11_30）

高橋真人の「プログラミング指南」第57回

UNIXとしてのMac OS X

〜Perlについて(3)〜

　こんにちは、高橋真人です。
　前回の最後に示したPerlスクリプトを実行されてみたでしょうか？

print A..Z;

　出力結果は、

ABCDEFGHIJKLMNOPQRSTUVWXYZ

となります。
　これは、Cで書いたところの

for (i = 'A'; i <= 'Z'; ++i) {
    putchar(i);
}

というコードと同じ結果を出力するわけですが、Perlのprintという関数は、引数にリストを取ることになっています。
　今、「引数にリストを取る」と言ったのですが、こういう状態のことをPerlでは「リストコンテキスト」と言うことがあります。そして、この考え方から「printはリスト演算子である」と言い、printという関数を何と演算子として扱うこともあるのです。
　何しろPerlでは関数と演算子の区別がかなりあいまいでして、つまるところ引数をカッコで囲った場合には関数と呼び、囲まない場合には演算子と呼ぶ、というちょっとビックリな決まりになっています。
　Perlのこういう柔軟というか、いい加減というか、慣れないとかなり違和感のある考え方は、逆に慣れると表現力を広げるための助けとなることも事実です。
　ところで、「リスト」という言葉を使いましたが、リストとはPerlではどんなものなのでしょう。
　リストの説明をする前にまず、Perlにおける変数のお話をしたいと思います。Perlでは主な変数の型として、スカラー変数、配列変数、ハッシュ変数というものがありますが、使用頻度の高い最初の二つに関してとりあえず取り上げてみます。
　スカラー変数というのはCでいうところの変数とほぼ同じような感じのものですが、基本的には何でも入ります。具体例を示せば、

$string = 'Hello world';
$number = 256;

というように文字列でも数字でも入るのです。ただ、スカラー変数である限り、必ず頭に$を付けなければならないということになっております。
　一方、配列変数はCで言う配列と同じように複数の値を保持できる仕組みですが、スカラー変数と同様、基本的に何でも格納できますので、一つの配列の中に数値や文字列が混在することも可能です。具体的には、

@array = ('Hello', 256, 'world');

というような感じで、配列変数に値を格納する場合に、複数の値を同時に与える時には、それぞれの値をカンマで区切った上でカッコでかこんでやります。配列変数の場合は、必ず頭に@を付けなければなりません。
　やっかいなのは、配列の特定の要素に個別に値を設定するケースです。たとえば、上記の@arrayという配列変数の2番目の要素を128に変更するとしましょう。この場合、コードは

$array[1] = 128;

となります。
　初めてPerlに触れる人がほとんどと言ってよいほどつまずくのがこの部分で、「@arrayというのが変数の名前なのだから、頭は@じゃないのか？」と疑問に思うのですが、配列の各要素はそれぞれがスカラー変数になるので、$でなければならないというのがPerlのルールなのです。ちなみに、@arrayという配列変数があったばあい、$arrayというスカラー変数を作ることは可能で、さらにこの二つの変数は完全に別のものであるということになります。
　こういった、Perlに独特の文法規則が入門者への敷居を高くしていることは事実でしょうが、慣れてくるとかえって便利に思えてきます。
　さて、話をリストに戻しましょう。上記の配列に値を代入する例で、値をカンマで区切ったものをカッコで囲んだ例が出てきましたが、実はこれがリストです。配列も、多くの場合リストのように振る舞うため、リストと配列の区別が付きにくいのですが、リストと配列はPerlにおいては明らかに別のものです。実際、両者の違いが出てくる状況はあまり多くはないため、最初のうちはなかなかこの辺の区分けのできない方も多いようです。
　そんなわけで次回は、このリストと配列の違いという点についてさらに解説してみたいと思います。

ニュース・解説

今週の解説担当:小池邦人

Carbon ドキュメント & サンプル ＆ SDK ナビゲーション（2004/12/03）

【開発環境】

各方面からの話をまとめてみますと、Apple社がNewGWorld()やCopyBits()を含むすべてのQuickDraw APIを抹殺しようと考えているのは明らかです（笑）。もう少し具体的に言えば、CGrafPortに依存するAPIをすべて消し去り（代用APIを用意する）、描画に関してはCoreGraphics（Quartz 2D）のCGContextRef環境のみを許するということです。そのうちOpenGLの描画環境も統合するかもしれません。まあ、すぐさまAPIそのものを消してしまうと動かなくなるCarbonアプリケーションが続出しますので（笑）、そんなに早急には断行できないでしょうが、将来的には開発環境がらみでAPIの使用をロックするかもしれません？　つまり、XcodeではCMFアプリケーションが開発できないようになっているのと同じ状況になるわけです。

QuickDraw APIはスレッドセーフでもありませんし、GPUの能力も生かしていません。仕様自体も古く、現状のMac OS Xシステムにはマッチしなくなってきています。逆に、それを使用することが処理のボトルネックになっているケースもあるわけです。Apple社側でもその点を重視しており、「Transitioning to Quartz 2D」といったドキュメントを提供し、描画処理をCoreGraphicsへ移行するようにと説いています。そのドキュメントを参考にし、QuickDraw 関連のAPIをすべて除外しても、現状の自作アプリケーションの開発が継続できるかどうかを詳しく調べてみました。各Managerのヘッダファイルを参照すると、QuickDraw依存 API（例えばRegionとかPictureを使うもの）は随分と新しい物に置き換えられていることが分かりました（もしくは仕様の拡張で対応している）。

ただし完全に準備万端かと言うと、そうでもないのが現状でして（涙）、Mac OS X 10.4（Tiger）においてより完璧になるよう努力中と言ったところでしょうか？　個人的な要望としては、CoreGraphics APIにはメモリ内のビット操作やメモリ移動に関わるAPIがないので、それらを新規に追加してもらいたいと思います。例えば、CopyBits()における部分的な画像（メモリ）転送や、CopyMask()とRegionによるマスク処理などは画像描画のみに利用されているわけではありません、オフスクリーン間での特殊なメモリ操作にも頻繁に活用されているのです。こちらの方面はTigerのCore Imageが受け持つことになるのかもしれませんが（なのか？）、QuickDraw依存度の大きいQuickTimeも含め、QuickDrawとCGrafPortが完全に消滅したとしても、Carbonアプリケーションの開発者がまったく困らないような完璧な準備をお願いしたいと思います。

【テクニカルドキュメント】

前回から12月3日の期間中、Apple社のDocumentationサイトにはドキュメントが17登録されました。WebObject関連のドキュメントも6つあります。このうち新規のドキュメントは「Pasteboard Manager Programming Guide」のみです。Pasteboard ManagerはCarbon FrameworkのScrap Managerに取って代わるAPI群であり、Clipboardを用いたCopy&Paste処理に最新の仕組みを提供します。ちなみに、Pasteboard ManagerはMac OS X 10.3以降でしか利用できませんので、アプリケーションに実装する場合には注意してください。前回紹介した「Pasteboard Manager Reference」と同時に参照すると良いでしょう。残りのうち「Component Manager for QuickTime」の内容はかなり変更されていますが、それ以外のドキュメントはマイナーな変更のみです。

「Apple Human Interface Guideline」（PDFあり）
「Cocoa Bindings Reference」
「Component Manager for QuickTime」（PDFあり）（改編）
「Core Foundation Reference」
「Deploying Applications」（PDFあり）
「Enterprise Objects」（PDFあり）
「Initializing QuickTime」（PDFあり）
「Kernel Programming」（PDFあり）
「Low-Level File Management」
「Outline Views」
「Pasteboard Manager Programming Guide」（PDFあり）（初版）
「QuickTime Overview」（PDFあり）
「Web Kit C Referenc」（PDFあり）
「WebObjects 5.2.3 API Reference」
「WebObjects Dynamic Elements Reference」（PDFあり）
「WebObjects Extensions Reference」（PDFあり）
「XML Serialization」（PDFあり）

http://developer.apple.com/documentation/index-rev-date.html

前回から12月3日の期間中、新規のテクニカルノートはひとつも登録されませんでしたが、新しいテクニカルQ&Aは2つ登録されました。「SetSoundMediaBalance balance parameter clarification」は内容の改訂です（日本語訳もあり）。「My custom item dismisses my Navigation Services dialog」の方は、Mac OS X 10.2におけるNavigation Serviceのバグの回避方法について解説されています。

QTMTB49「SetSoundMediaBalance balance parameter clarification」
QA1381「My custom item dismisses my Navigation Services dialog」

http://developer.apple.com/technicalqas/index-rev-date.html

【サンプルソースコード】

前回から12月3日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードがひとつだけ登録されました。OpenGLを用いた描画でのテクスチャの活用を紹介したCocoaサンプルです。

「NSGLImage」（Cocoa&OpenGL関連）

http://developer.apple.com/samplecode/index-rev-date.html

【デベロップメント SDK】

前回から12月3日の期間中、Apple社のSDKサイトには新しいSDKはひとつも登録されませんでした。

http://developer.apple.com/sdk/

MOSAからのお知らせと編集後記は割愛します