著作一覧 |
一時間って、単になんらかの単位程度のつもりだったけど、本気で一時間(60分、360秒)になりそうなんで、ちょっと考える。
なんと、入手可能とは思わなかった。
追記:買ってしまった……
何人もの人が、この問題に挑んでは、それほど良い説明をできなかった。と思う。でも、確かに心地よいのは事実として感じる。ではなぜだろうか?
能書きだけなら、C#やJavaとそれほどはかわらない。もっとも、akrさんと継続はどちらにも組み込まれてないけど。
インタプリタは……は、TurboC(しかおれは知らないがTurboPASCAL知ってる人はそっちが本家というのだろうな)なら、書いてボタンを押せばその場で実行できるわけで、これもそれほどまでの差ではない。
core吐いたら処理系内部までgdbで追える……それって心地よいわけではないですから。
でも、考えてみれば、心地よさの理由というのはそれほど大したことではないのだ。
それは、言語設計/開発者が、ユーザー=プログラマを信用している、というのが原因だ。
つまり、プログラマが言語および組み込みライブラリを相当自由に変更できるということ。
一見自由そうな.NET Frameworkですら、System.Stringはsealされている。ところがRubyの場合は、なにからでも派生できるは、後付でメソッドを追加できるは、要するになんでもできる。
あとから、すべてのルートのObjectにisBlank?(ちょっとJava風味で書いてみた) なんていうメソッドを追加することができるというのが良い例。
それは、信頼されているって感じるのって心地よいよね。調子乗っていつもより高いところに昇っちゃうぞ、ってことだ。
さて、それはそう得心した。
で、この知見は敷衍できることなのか? それが問題だ。
昨日、TableAdapter使いまくりしてたら、やっぱり腑に落ちないのが出てきたよ。
前提条件:MSDTC使いたくない。でも、トランザクション必要。
となれば、SqlConnection.BeginTransaction() ですな。
で、TableAdapterは、Connectionプロパティを公開してくれている。明示的にOpenしておけば、自動開閉しないとか、TableAdapterクェリの生成メソッドもそのあたりはわかっている。
でも、だめなんだな。
というのは、TableAdapterクェリ生成メソッドは、Connectionの状態は見てくれるが、トランザクションに参加しているかどうかは見ずに、内部的にこっそりCommandを使う。ちょっと待て。
でも、抜け道が無い。
しょうがないから、TableAdapterクェリ生成メソッドを丸ごとコピー&ペーストして、自分でSqlTransactionをCommandに突っ込むことになる。
で、partialクラスが役に立つ。そのあたりをわかっているので、ジェネレートされたクラスにちゃんとpartialキーワードが付いている。(MSDNにも書いてある)
ジェネレーションギャップパターンのインスタンスいっちょあがり。
でも、さらに待て。デザインパターンが有効なのは、その言語(この場合はADO.NETというフレームワーク)の機能不足でもある。Command取り出しをフックできるようにするとか、Commandの下準備をするデリゲートを与えられるようにしていれば、むしろそのほうが良いのではないだろうか。
delegate void PrepareCommand(Command c);
public void GeneratedUpdateMethod(object param1, object param2, PrepareCommand block)と、生成して(と書いてから気づいたが、デフォルト引数がないから、ほとんどの場合、nullを最後に書かされることになるのでだめか)。
というか、単にpublic void GeneratedUpdateMethod(object param1, object param2, SqlTransaction transaction) を生成してくれるだけで良いのかも。というか、MSDTCを使えという方針なんだろうか。
たとえば、次の会話は理解できる。
「ほんと、ハンバーガーってゴミだよな。あんなの食べるやつってウィンピー以外のなにもんでもないよな」
「おい、そのセリフはバーガーキングを食ってから言いな」
あるいは、
「東郷青二(字、忘れた)って、お菓子の看板書きだろ。あんなのが絵描きとして評価されてたなんて、昔の連中はほんとに物を知らねぇよな」
「そのセリフは、やつの自画像を越える画を描いてから言いな」
つまり、ある話題の対象に対して無知から来るネガティブな物言いに対して、ケチをつけるというのはわかる。
次のもわからないではない。
「あーおいしかった。ハンバーガーって本当においしいなぁ。ありがとう、ドナルド!」
「おい、そのセリフはバーガーキングを食ってから言いな」
とか
「東郷青二の画っておしゃれですてき」
「まずはマリーローランサンやドローネを見てから言いな(もっとも全盛期のおしゃれではない東郷青二はもっとすごいがな)」
くそみたいなもので満足している人に対して、もっと良いものに眼を向けろというのもわかる。
わからないのはこういうのだ。
「バーガーキングのワッパー食って、ああ満足だ。」
「不二家レストランのハンバーグ定食にはライスもついているんだぞ」
何が言いたいんだ? きみが不二家レストランが好きなのは結構。まあ、味も同格なんだろう。不二家は戦前から営業してる? それは知らないけど、だからどうした?
パターン1:まずいもののせいで、全体の評価を低くしてしまった人に、良い例を示す
パターン2:まずいものに満足している人に、より良いものを示す
この2つのパターンとは異なる。
パターン3:良いものを評価していたら、なんか全然関係ないものを持ち出してきて、そっちのほうが良い(ライス「もついている」んだぞ、という示し方。でも、それ、全然話題にしてないんだけど)と言い出す。
でも、根本的に間違っているのは、ハンバーガー(バンズで食う)の話をしている=みんなバンズを食うことを前提にしているのに、かっこじゃなかったライスを持ち出して来られてもねぇ。だからどうしましたか? という感じだな(これは、巷で話題の分裂君の話ではない。あれは、マックとバーガーキングのどちらを評価するかというパターン2だから。2つ上のは直接は関係ないからその意味ではパターン3)。mixiね。
パターン3には2種類がある。1つは土俵を変える、あるいは仕切り直しだ。勝負がつかない以上、見方を変えるということだ。これは必要でしょ。
問題はもう1つのほうだ。これはパターン1の裏返しに過ぎない。早い話、無知から来るケチ(お、韻を踏んだ)。もうひとつは、老人の繰言(昔は良かったというやつ)。このタイプは見分けやすい。大抵、ツッコミをおそれて自分から「わしゃ、ケータイってのはよくは使ったことはないんじゃが、モールスの発明した電信技術は、すべてを含んでいるんじゃぞ。ツートンの2つだけで、あらゆることを表現できて……」という具合に、話題の対象を知り抜いてはいないと弁解してから物言いを始める。まずは、ケータイってのを使いこんでから、口を開け。
「いや、よくは使ったことはないんじゃが、結構は使っておるぞ」「ふむ。比較はちゃんとした上で言っているのか。で、誰が使えるの? どこで手に入るの?」「どこにでもあるし、みんなが使っておるぞ。わしは80年間使っておるぞ」「そりゃ、単に、あんたが慣れているってだけだろ」
あと、現実性というものがない(浮世離れという言い回しがある)というのも特徴か。
ジェズイットを見習え |
JavaScriptはObject.prototypeやFunction.prototypeが変更出来るけど心地よくない気がする。
そのへんは構文に秘密があるのかも。<br>タイプすると冗長だけど、endと書くのがキリが良い感を醸し出すとか、そんな程度のことだけど。あと、JavaScriptよりそこはかとない高級感(じゃないな。気分的にはJavaScriptのほうが高級に感じる−−フレンドリーな感じ、ばかみたいだけど)とか。JavaScriptとはむしろ敷居が高い感じがする。