1. プログラム プログラム名:パネルディスカッション:「LLとオブジェクト指向について」 オブサーバー: まつもとゆきひろ(ネットワーク応用通信研究所) 発表者名: Perl: 宮川達彦(エッジ) PHP: 藤本真樹(TUNEBiZ) Python: 磯蘭水(日本Pythonユーザー会/青山学院大学) Ruby: 中田伸悦 記録者名: 安武弘晃 磯辺和彦 桝形誠二 渋川よしき 2. 時間 開始時刻：2003/08/09 13:36 終了時刻：2003/08/09 14:48 (質疑応答：2003/08/09 14:49 〜 15:10) 3. 発表の概要、論点 Perl,PHP,Python,Ruby について、それぞれのオブジェクト指向に対するアプローチや実装方法、その歴史や考え方について紐解く。 なぜオブジェクト指向か?どうやって行うか?というところが論点。 4.1 発表の流れ LLとは?(まつもとさん) PerlのOO(宮川さん) PHPのOO(藤本さん) PythonのOO(蘭水さん) RubyのOO(中田さん) 各言語のスタンスへの感想 質疑応答とディスカッション 4.2 内容 Lightweight Languageとは?(まつもとさん) 2001年、MITで行われたLL1というセミナーを開催するにあたって、開催者のMITのGreg Sullivanが導入した概念。しかし、明確な定義は無い。アメリカはあまり細かく定義をしないで、なんとなくこうなんだ、という雰囲気がある。 LLはPerl、List、MLなどを含む。ダイナミックランゲージと言ってしまうと、Haskellを除外することになる。スクリプトと言ってしまうとMLを除外することになってしまう。これらの言語をすべて内包する概念としてLeightweight Language(以下LL)という言葉が作られた。 あくまでも、便宜上の概念であり、深い意味はない、という状態だった。 2002年に、まつもとゆきひろさんが2002年のLL2で講演したときに(プレゼン資料はwww.ruby-lang.org/en/ll2/index.html)Leightweight Languageの俺定義を作った。 俺定義という のは、言葉のイメージから作り出した自分独自の定義。的確な場合もあれば、不的確こともある。俺定義というのはプログラマにとって、ある意味、危険だけれども、楽しいところである。 それによれば、「より少ない能力の消費で開発できる言語、少ない労力、少ないストレスでプログラミングできる」というものである。特に異論はなかったので、合意はとれた、と自分で勝手に解釈している。 たとえそのソースのアーカイブが何MBあろうと、脳力をより少なく使えば Lightweight。Perl も ソースコードが55MBあっても Lightweightを名乗る資格がある。 LL な言語については、何がいいとか悪いとか議論をせずにお互い助け合っていこう、ということが大切である。 Rubyに触れた外国人の反対意見の典型的なものには以下のものがある。 * スクリプト言語にOOはいらない * Rubyはスクリプト言語には良すぎる LLはあらゆる領域に発展している。規模の大きな開発も行われるようになってきた。システム監視でも DB admin でも使用する。LLを使うことで、複雑度を軽減し、脳力消費を少なくすることができる。 最近のLLには必ずオブジェクト指向が含まれる。流行だから、というのもあるかもしれないが・・・dynamic binding/polymorphismは小さいプログラムにも有効である。 結論としては、「LLにオブジェクト指向は必要である」と言うことができる。 Perlのオブジェクト指向の基本(宮川さん) 宮川さんはCPANで一番多くモジュールを登録している。最近、Mat サージェントというXML の人がいて抜かれそうな勢いで登録をしているが、またくだらないもの作って抜かしてやろう、と画策している。 今日のPerlでの紹介のポイントは、PerlでOOをやろうと思った場合の基本的なことや、世の中的にどのように使われているか、という事例紹介などをしたいと思う。 Damian Conwayの「Object Oriented Perl」は非常にイイ本である。この本の一節を借りてPerlのOOを説明すると、「Perlにちょっとしたセマンティクスを追加してサポートされたのがPerlのOOである」ということである。 これからPerlの OOの紹介をしていくが、自分なりに解釈している定義なので多少違うかもしれない、というところもある。 まず Perl のOOではパッケージを作る。パッケージがクラスであると言える。パッケージの中で関数を作っていくと、それがメソッドになる。で、オブジェクトをbless参照渡しで返すような形で実装されている。オブジェクトを取り出すことはできず、リファレンスでオブジェクトを取り扱う。 PerlのOOにおいて、メソッドやアルゴリズムの再利用をする仕組みは、@ISA配列で表現することになる。@ISA 配列にスーパークラスを記述する。また、継承をするのに最近お勧めなの はbaseプラグマ。use baseという形で記述する。@ISAを使用するよりはその方がいいと思う。詳しくはマニュアルを参照。多重継承もできる。 リファレンスカウンタが0になり、オブジェクトが破棄される時にDESTROYメソッドが呼ばれる。これがデストラクタ。余談だが、自分ですべて大文字のmethodを作ると、将来的にバッティングする可能性があるので、注意が必要。ただし参照されているとオブジェクトが破棄されないので、循環参照になってしまい、メモリリークの問題を引き起こしたりする問題がある。 AUTOLOADを定義しておくと、未定義メソッドの呼び出しを探知することができる。クラス内にメソッドが見つからない場合にアクセサを自動生成できるので、便利。ただし、積極的に使うと継承後の挙動で問題が出たりするため、頻繁に使うのはあまりお勧めはできない。 演算子のオーバーロードをサポートしている。overloadプラグマで演算子を規定できる。オブジェクトがコンテキストによって振る舞いを変える。数字コンテキストでは数字がでてくるし、文字列のときは何かをする、ということもできる。文字列化は結構便利。また、fallback でメソッドが見つからない場合の動作を指定できる。あまり使わないが、文字列のときは、新しいオブジェクトをnewしてテンプレートに埋め込んだりすることもある。5.6からはdereferenceをoverloadできたりする。 UNIVERSAL はすべてのオブジェクトの祖先クラス。というのは、ほんとは正しくないのかもしれないが、９割正しい。UNIVERSALにはcan(),isa()というメソッドが提供されていて、どんなオブジェクトからも使える。またUNIVERSALにメソッドを追加するとすべてのオブジェクトからそのメソッドを使えるようになるので、それにAUTOLOADを追加すると、強力なことができる。すべてのクラスで未定義のメソッドが呼ばれた場合、UNIVERSALの AUTOLOAD が呼ばれる。 可視性という意味で言うと、public,private,protectedは用意されていない。これについては、自分でコーディングルールを作り、privateメソッドは_を先頭につける、というような形でやっていくのがよい。自分だけでやっていれば、それでいいが、外に公開するものを作りたい場合はきちんとやる必要がある。Paranoiaな人はcaller() でチェックして、自分がどこから呼ばれているかをチェックして、自分以外から呼ばれたら死ぬ、とかすればよい。ただ、それでもcallerをoverrideできるので、いたちごっこで完全に守ることはできない。あるいはClass::Fields, Attribute::Protectedなどを使う。 PerlであればOOでもいろんなやり方がある。オブジェクト指向にしても、Perlは色々出来るよというのがLarry Wallの言い方。例えば、デザインパターンについて、PerlのOOを使うとこんなに簡単にできるんだ、ということを紹介したいと思う。C++でやりにくいからパターン作ったと思われるのもあるので、Perlでは気休めにすぎない面も多々ある。 Singleton Patternについてだが、CPANにモジュールがある。Calss:Singletonである。スタティック変数はレキシカル変数を利用。パッケージ変数に格納。オブジェクトが1つしかないことはどうやっても保証はできないので、意味があるか?というと気休めしかならない、とも言える。が、簡単にできる。目印として使う。 Decorator PatternはAUTOLOADを使うときれいにできたりする。未定義メソッド呼び出しを利用して、メソッドの転送をすることができるので、委譲が簡単にできる。元のオブジェクトを生成してClass:Decoratorとする。Class:...というのがCPANにたくさんある。また、 Object::PerlDesignPatternというのがある。とても参考になるので、見てみるとよい。 多重継承はmixin.pmを使うことができる。Aspect Oriented Programmingもできる。動的にメソッドを上書きし、フック処理を行った後にもとのメソッドに処理を転送することで実現している。多重継承はやはりダイアモンド型の問題あり。 rubyism.pmというものもある。Rubyの機能のいいところを盗みましょう、というもの。それに加えてautobox.pmを使う。そのためには Perl 5.8.1 RC4 へのパッチが必要であるが、rubyismとautoboxを使えばPerlだかRubyなんだかわからないプログラムを書くことができる。 実際にPerlでOOが現場で使われている事例を挙げたいと思う。SledgeというWebアプリケーションを作るフレームワークがある。これが現場で使えるか?というと、実際に使えている。 最後の方は時間が足りなくなってあまり説明できなかったが、Perl の OO で大事なのは、結局何をしているかわかる人がやる、何を使っているかわかるようにモジュール化してみんなで使う、ということだと思う。 PHPのオブジェクト指向機能(藤本さん) 藤本さんはPHPの CVS commiterの一人。Zend Engineの国際化を気が向いたときにやっている。PHPの開発者を募集しています。できればかわいい女の子がいい。 PHPの OOってどうよ?というところだが、たいした機能はない。それについてどういう思想・方向で進んでいるか?について説明したいと思う。 初期PHPはオブジェクト指向は非サポート。Classってなに?の状態で、OO的な要素はまったくなかった。PHP3からは、クラス、継承、コンストラクタがサポートされたが、必ずDeep Copyになるという致命的な欠陥があった。同じオブジェクトを複数の変数に入れることができないので、同時に参照するということができなかった。PHP4ではリファレンス(参照)がサポートされ、Deep Copy問題が改善された。同じオブジェクトの実体を複数の変数で使えるようになったので、なんとか使えるね、というレベルになった。文法は&=。また、速度も改善された。PHP5ではアクセス制御、デストラクタ、コピーコンストラクタなど色々と追加され、変数への代入も参照コピーがでフォルトになる。詳しいところは、現在も仕様が変わっており、これから変わる可能性があるので、今回はパス。 PHPには哲学をリードするカリスマ的リーダーがおらず、数人でわいのわいの、と作っているので、Perl や Ruby のようにかっちりした思想はない。まつもとゆきひろさんの「Rubyは快適な自転車を目指す」という文脈を借りれば、PHPでは「折りたたみ式補助輪付き自転車」辺りが妥当。右も左も分からないような人たちにも、それなりに理解している人達にもある程度使えるようなものを目指しているが、あくまで建前。言い換えればHTMLしか分からない人も使えるし、慣れた人も使える言語。基本的にはglue(のり)としての言語であり、HTMLとDBをつなげるという「決まりきった機能を簡単に提供」といった観点からスタートしている。あくまでオブジェクトの機能は追加機能。ここが他の言語と明らかに違う点。 PHPにおけるオブジェクト指向「的」機能 PHPのオブジェクト指向の実装はシンプルであり、継承/メンバ変数/コンストラクタ/メソッドと、簡単な機能のみ。単純とも素朴とも猪突猛進とも言える。ただ、これだけでも、オブジェクト指向がわかっている人ががんばれば、それなりにいける。PEARを見れば涙ぐましい努力をしているような跡が見られる。そこそこ行ける、ということだろう。Rubyのincludeのようなおしゃれは無理。Singleton/Adapter/Composite/Factory/Strategy等がある。 内部構造としては、コア部分はスクリプトエンジン(Zend Engine)が担当。スクリプトを一旦独自のopcode配列にコンパイルして実行。基本要素はzend_op/zval/zend_function_entry/zend_class_entryの４つでシンプル。内部構造を知ると、クラス概念が、いかにあとづけか、ということがわかる。やはり後付けであってRubyやPythonのように純粋なオブジェクト指向ではない、というところである。ただし、これが、いいか悪いか、別問題。 OOについてPHPとほかの言語との差異を見ていく。PHPでは通常の代入ではディープコピーになってしまうので、オブジェクトを渡す場合はリファレンスで渡す必要がある。文法は&=。 スコープについては、メンバ定数やメソッドにアクセスする場合は$this付ける必要がある。 良いか悪いかは別として、PHPは純粋なオブジェクト指向ではない。よくも悪くもシンプル。言語が提供する機能はほぼない、という状態。こういうことがしたい、と思ったら、そういう関数を探すのがPHPの思想。PHPみたいにすべて関数を呼んで何でもできる、というのがいいのか?ruby 風なのがいいのか?は後のディスカッションで議論したいと思う。 PHPも一貫性があるという意味でシンプル、というRuby的な発想もある。PHPでも好きな人は大規模なオブジェクト指向のものもある。Ampolusとか、PHP-Nukeとか。 Pythonのオブジェクト指向機能(蘭水さん) 蘭水さんは青山学院大学で教員をしている。Lispをしていたが、まわりにわかる人がいなかったので、Pythonに乗り換えた。 Python での OO は keyword が「名前空間」。Pythonのオブジェクト指向を知る上では、遠回りしてでも知っておくべき概念。名前空間がオブジェクトとして表現されているのが特徴。それぞれの名前空間が階層構造的に作られていくというイメージになる。 名前空間には、グローバル、モジュール、クラス、インスタンス、ローカルの５種類ある。Pythonの"."は、名前空間解決演算子と考えるべき。これを理解するためには、dir()という(便利だが)ふざけた名前の関数がある。これを使うと、名前空間のメンバーの一覧をリストに入れて返してくれる。例えば、"hogehoge"というモジュールがあったときに、dir(hogehoge)とやれば登録されている名前が一覧で表示される。moduleにimportされているmoduleもdirで見ることが出来る。dir(moduletest.sys)を実行すると、sysの中身がみられる(sysはネストされたモジュール)。 ファイルもモジュールである。すべてのpyファイルはモジュールになる。それぞれ固有の名前空間を持っている。ファイル内のトップレベルで関数やオブジェクトを作ってもモジュール内に作られる。モジュールを利用するためには、import、あるいはfrom - importを使う。後者は、import後に、選択した名前を現在のローカル名前空間に取り込む。 __init__がコンストラクタ。継承した場合に、親のコンストラクタを呼ぶ場合には、SuperClass.__init__(self, 引数)と書く。親クラスのコンストラクタは明示的に呼ぶ必要がある。メソッドの引数の最初にはselfを必ず入れる。selfにはインスタンスの実体が入る。thisと書いてもいいが、selfと書くのが慣習になっている。メンバ変数を見たい場合はself.なんとかで扱うようにする。 あるクラスから二つのから別のインスタンスを作ったとすると、それは独立して、新しいインスタンス名前空間を持つことになる。クラスの名前空間とインスタンスの名前空間は独立していて干渉しない。インスタンスを作ったあとに、クラスとは別にインスタンスごとにがんがん新しいデータやメソッドを追加できる。 クラスのメンバはインスタンスではなく、クラス名を指定して、メソッドを呼ぶ。名前空間を常に意識するのがPython流のオブジェクト指向と言える。 Pythonではすべてオブジェクト。Pythonの2系列からは数値などの組み込み型もクラスになった。Pythonの悪口で言われるところが1つ減った。 Pythonのシステムそのもの中身がどう動いているか?が見れるようになっている。メタデータへのアクセス機構が整っているため、オブジェクトのメタデータのすべてをコントロールすることができる。ソースを見なくてもインタプリタからPythonが分かる。たとえば、スーパークラスなどにアクセスしたり、バイトコードにアクセスしたりできる。 悪用すると、実行中にメソッドを入れ替えたりできる。失敗するととんでもないことになるが、まったく別の所で関数をつくってそれをそもそもそういうメソッドがあったかのように追加することができる。これをうまく利用しているのがZope。これがあるからZopeは動く オブジェクト指向言語というよりは、ダイナミックオブジェクト環境であると言える。すべてが見えて、いじることができて、動的に書き換えられる。ある意味Lisp並み。ただし()はいらない(笑)。使いこなせばすごく強力。「ネタプログラミング」に最適。 Rubyのオブジェクト指向機能(中田さん) ruby-lang.orgという組織は存在しない。無所属ということになる。流しのプログラマー。今日は「深い」ところにはあまり入らず。 「すべてがオブジェクト」というのはRubyのいくつかある特徴の重要なひとつ。そうでなければ Ruby ではなくなってしまう。すべての値がオブジェクト。オブジェクトでないものはRubyにはない。すべてのクラスはObjectクラスを祖先にして、そこから派生するもの、となっている。 値というのは操作対象になるものすべて。整数も浮動小数点もオブジェクトになっている。配列もそのためのクラスが用意されています。C++ ではクラス自体はオブジェクトではないが、Ruby ではクラスもオブジェクト。モジュールもシンボルもオブジェクト。制御構文はオブジェクトではない。変数もオブジェクトではなく、代入しか行えないため、インクリメント(++)を実装することができない。プログラム自身はオブジェクトではないのでPythonのようにバイトコードを直接いじるようなことはできない。 nilもNILクラスの唯一のオブジェクト。true,falseもそれぞれのクラスに所属するもの。C++ や Java のようなプリミティブ型というのは存在しない。 RubyはClass Basedな言語ではなく、本当のObject Orientedな言語である。クラスでのみメソッドを定義できるのではなく、オブジェクトも自分自身の特異メソッドをもつことができる。 クラス、モジュールはメソッドを定義する器(の1つ)。すべてのオブジェクトは何らかのクラスに属する。モジュールはインスタンスは作ることができないが、継承させることはできる。Javaのインタフェースと違って実装継承することができる。Mix-in用。クラスもモジュールもそれぞれ別個の名前空間を持つ。 RubyはObjectクラスを頂点とした、ツリーを形成する。単一継承のみをサポートする。 Mix-inは、擬似親クラスとしてこそっと継承ツリーに挿入される、という形式で実装されている。 デザインパターンについては、特異メソッド/クラスを応用して定義できる。そのオブジェクトだけのメソッドを定義することができる。ほとんど必要のないものだろう。(他の言語でsingletonが紹介されていることをふまえて)Rubyではsingletonはあまり使われていない(必要ない?)(笑)。特異メソッド/クラスを応用している例ではPrototype、Singleton、Adapterなどがあり、クラスオブジェクトを応用ではFactory、Builder、Bridgeがある。Builderの具体例としては、Net::HTTP::Proxyがある。 RubyにとってOOは楽しいプログラミングのための道具の一つ。自然にオブジェクト指向。難しく考える必要はない。 各言語への感想 司会： それぞれの言語についての Policyや思想などについての感想を頂きたいと思います。 宮川 Pythonのスライドのテンプレートがかっこいいですね。 磯 スライドを作っている時にP1の柴田さんができたと言ってMLに流していた。それを見たらかっこよかったので利用させてもらいました(笑) 宮川 スライドもいいんですが、Pythonのmethodの挿げ替えなどはPerlと似ていると思います。Perlでもシンボルテーブルが見られます。 藤本 オブジェクト的な考え方を後付けでつけたのはPerlとPHPだと思います。やはりそのあたりは微妙に苦しいかなぁ、と感じますね。 PHP5でさらにあと付けをしようとしているからさらに大変そう。 頑張るのは人なので、PHPが好きな人や頑張りたい人は、がんばればよいと思います。実際に頑張っている人もいます。 個人的には Rubyを使っています。Pythonもいいですね。 磯 やはりみなさんインタープリタ言語でOOをやっているんだな、と感じました。 実装方法などは違うかもしれないけれど、根っこにあるのは同じかな、と思いました。他のものも触ったことがないが、食わず嫌いだったが食べてみよう、と思いました。。 最近はC#ばっかり書いています。Perlのドルマークとかは何とかならんのかと。気持ち悪い! じゃまくさい! 小飼 あれがイイという人もいるんです。ハンガリアン記法が好きな人には適している。 ハンガリアン記法が好きな人もいるから、そういう見方でもいいんじゃないか? 磯 ハンガリアン記法も好きじゃないんですよ。記号に特別な意味がないのがPythonのいいところ、です。 中田 他の方の話で、すべてRubyの機能を説明してもらってしまった。 それぞれに面白いと思います。それぞれ似ているところもあります。 楽をしたのかワリを食ったのか(笑) 質問者 Perlを仕事で使っていて10000行ぐらい書きました。PerlとPythonが考え方として似ていると思います。Perlはよく使うが嫌いな言語でもあります。今日のアンケートの「よく使う言語、好きな言語、嫌いな言語」という項目で私はPerlではすべてにチェックを入れました(会場：笑)。Perlの嫌いなところは、いちいちblessしないといけないところと、$変数->{フィールド}などずらずら書かなきゃいけない所です。 rubyismとかautoboxを使うと楽になるんでしょうか? 宮川 selfを書くのがめんどくさいからsource codeをフィルタリングするものを作ったりしている人もいたが、あまり離れ業をやってしまうと、後からコードを読む人が泣くことになる。標準で使うしかないんじゃないかな? 小飼 そういうものはCPANにアップしてみんなに使ってもらえば、解決するのではないか? まつもと Perl5はPythonから取るといっていたので、似ているのは事実。 Perl6はRubyから取る、といってたけど。 質問者 まつもとさんの日記を拝見させてもらっています。この日記の中でオブジェクト指向が難しいという話がありますが、皆さんから、難しくないぞと言う意見があったら聞きたいと思います。 自分は Rubyで始めてやったけど、ラクだと感じています。 司会 シンプルさについてのコメントをお願いします。 宮川 データとデータ処理をまとめて書けるから楽だと思います。 私は最初Perlから入ってJavaAppletを作っているときにオブジェクト的な作り方に触れました。Javaをやってる人は最初はPerlのオブジェクト指向は気持ち悪がるけれど、2〜3ヶ月もすれば慣れてくるようです。 非OO言語から来た人はなかなか難しいようですが、モジュールやフレームワークがあるので、使ってその流儀に慣れてきてから、そこから改めてオブジェクト指向を勉強するのが効率が良いのではないでしょうか? 藤本 オブジェクト指向というのは、分厚い本などがあって難しいと思われてるイメージがあるだけじゃないか?と思います。関数だけでもプログラムは書けるので、とりあえずやってみることが大事だと思います。そのうちオブジェクト指向ライブラリを利用して慣れていくと良いと思います。 PHPに関しては、PEARはクラスライブラリになっているので、使っているうちに慣れてくるということがあります。それがきっかけになります。食わず嫌いは駄目。 PHPの特徴として初心者層がすごく多いです。慣れてくる人がもっと多いといいです。 磯 私はLispマシンのフレーバーで触れました。最初はなんだこりゃ?と思いましたが慣れて便利だな、これはいい、と思うようになりました。 大学の講義でC++を使ってオブジェクト指向を一年生に教えていますが、傾向として真っ二つに分かれるようです。すぐに慣れるグループと、ぜんぜん慣れないグループがあります。手続き的に物事を順序だてて考えることしかできない人にはどうやら抵抗があるようです。オブジェクト指向にすんなり入って来る人は、構造的に物事を捉えている人が多いみたいです。Cを教えているときにもやっぱり構造体が出てくるときにこけるグループと、すんなりそれを乗り越えるグループがいます。根は同じだと思います。 全体を俯瞰的に見る訓練を持つということがオブジェクト指向を身につける一歩となると最近の学生を見ていて気が付きました。 台場 カンでこれでもいいやって奴はOOになじめる 中田 言いたいことはすべて言われてしまいましたが.. 私が最初に OO に触れたのはC++でした。Cでやっていた時に自分でやらなければいけなかったものを言語がやってくれたので、楽でした。 オブジェクト指向は構造化言語の自然な延長だから難しくない、と思います。 な マニアな人にとって難しくないというのはあたりまえなんで、そうじゃない、難しいという意見は? 小飼 世の中の構造に比べれば、オブジェクトの方がとても簡単です。 オブジェクト指向で書く、というのは、登場人物がたくさん出てくるものを書くときはいい方法だと思います。一人しか出てこないときは手続き型でもいいんです。一人の登場人物で長大な物語をかける人は C でもいいと思います。 ワンライナーな人には必要ないけど、大きなストーリー的なプログラムを書くためには必要であり、あると楽です。 まつもと オブジェクト指向は難しく.. ない.. でしょ?。 どこにでもある概念ですし。C言語でもstdioでFILE型ポインタとfopenなどの関数があるが、それはオブジェクトとメソッド。ものがあってそのものにふさわしい手続きがある、ということを押さえればいいだけだと思います。 「哺乳類が」とか、「構造体がクラスになって」とか言い出すととたんに難しくなるけど、何でもいいからプログラムを組んでみて、他人が作ったクラスを使ってみれば、ああ、そうか、と分かります。 そうやれば誰でも難しいと思わないはずです。オブジェクト指向は難しくないと思います。 司会 時間が来たので以上で終わります。続きは飲み会で、質問を投げかけてみてください。 6. 発表の総括 Perl,PHP は後付けで、Python,Ruby は純粋に、といったような言語の特徴はそれぞれにありますが、根っことする部分、実現したいものは共通で、それぞれのアプローチの仕方がある、ということでした。どの言語でも OO をやると構えずに触っていて体で覚える、ということが大事です。 7. 所感 全体を通して、４種類の言語の特徴が出ていて、並べてみることにより、オブジェクト指向的開発、というのが何を意味するか? という構図が見えてきたと思います。 Java = オブジェクト指向的な構図よりもはるかに本質がわかる見方だと思いました。 他の言語と比べて、PHPで「LLとオブジェクト指向について」という点について発表するのは、ちょっとお題が厳しいかな?と感じましたが、PHPの限られたオブジェクト機能について偏見なく的確に発表していたと思います。 最後の「頑張るのは人なので。。。」という言葉が、非常に印象的でした。 蘭水さんの「スクリプト言語で行うOOは目指すところが似ている」というような言葉がまさにそうだと思いました。だからこそSWIGなんてものが作れるんですが。 初心者でもオブジェクト指向さえ分かればLLを使うことですぐに開発力を向上させられるのではないでしょうか?右脳的オブジェクト指向のススメは「オブ脳」というぴったりの本があります。 8. 特記事項 会場のサイズや雰囲気はよかったと思います。あまり商業的にならずにアットホームな雰囲気がよかったです。運営お疲れ様でした。 特になし。強いて上げれば進行の仕方が実にスムーズだった。 所感と特記事項は各ロガーの記述を列挙しました。やはり細かい部分で差異が生じるため、複数のロガーが記録してまとめるのは有効だと思いました。（渋川） $Id: p2.log,v 1.1 2004/03/24 04:00:36 ryuchi Exp $