vieweditattachhistorytopchangessearchhelp

モーフとプレイヤふたたび …とワークスペース変数、AC04 談義(ぉぃ)ちょっと

マニアックネタに走りがちなことから察していただけるように、ここまでくるともう、ストーリー仕立てで説明差し上げなければならないことはなくて、あとは実践あるのみって感じなんですよね(笑)。なので、最初の“3手”を復習を兼ねて再現してみましょう。--sumim - 2002-12-06, 15:49:44

>ストーリー仕立てで説明差し上げなければならないことはなく
そうですか(汗)∀ガンダムはダメって申し上げたので,どんなストーリーが展開するか期待していたんですが(笑)--人狼 - 2002-12-06, 16:04:11

あ、そういやデバッガやっていませんでしたっけね(^_^;)。--sumim - 2002-12-06, 16:05:54

あと、Genie の説明をして、Sqewton プロジェクトに突入して即最前線で戦っていただく…ってのもおもしろいかなとも(笑)。--sumim - 2002-12-06, 16:07:32

>デバッガやっていませんでした
あ,言われて見れば(汗)--人狼 - 2002-12-06, 16:11:07

>Genie の説明をして、Sqewton プロジェクトに突入して即最前線で戦って
ここはエリア88でしたか(爆)--人狼 - 2002-12-06, 16:12:00

まあエリア88で目覚めてびっくりする前に、とりあえず復習、かたづけちゃいましょう(笑)。Workspace の create textual references to dropped morphs を設定したあとに、モーフをドロップインすると現われる謎の文字列の正体は想像できますか?--sumim - 2002-12-06, 16:18:41

>エリア88で目覚めてびっくりする前に
実戦配備は決定なのですね(笑)光栄です.
>謎の文字列の正体は想像できますか
SketchMorphのインスタンスの名前でしょうか?--人狼 - 2002-12-06, 16:25:29

インスタンスの名前
(やはり菊池桃子風に)違います。(笑) 実はこれ、変数の一種なんです。ワークスペース変数って言ってこのワークスペースの中でだけ通用します。ワークスペース変数は簡単に作れて、例えば、
jinro _ #jinro
などとして一時変数の宣言なしに do-it すれば、jinro というワークスペース変数ができあがります。sketchXXX は、こうした操作(do-it)を経ずに、ワークスペースにスケッチモーフがドロップインされたときに作られたものです。--sumim
- 2002-12-06, 16:33:17

>(やはり菊池桃子風に)違います。(笑)
やはりCMを見なくてはならないのですね(汗)
>ワークスペース変数
むぅ,そうですか.この変数はワークスペースが閉じられるまで有効なのですか?--人狼 - 2002-12-06, 16:42:03

この変数はワークスペースが閉じられるまで有効なのですか?
実質、そういうことになります。情報としては、このウインドウの情報を把握しているオブジェクト(我々が accept したときに対応する人ですね。Workspace のインスタンス)内にあるので、同オブジェクトが消滅するまで有効です。--sumim
- 2002-12-06, 16:51:27

これら(だれが主人で、どこにどんなふうにワークスペース変数の情報が束縛されているか)は、ワークスペースをモーフとして選択しそのデバッグハローから、エクスプローラで modelbindings とたどることで確認できます。--sumim - 2002-12-06, 16:54:38

>ウインドウの情報を把握しているオブジェクト内
了解です.Workspaceのインスタンスですね.--人狼 - 2002-12-06, 16:57:42

>デバッグハローから、エクスプローラでmodelbindingsとたどる
デバッグのメニューも豊富ですね.これは一苦労しそうです.--人狼 - 2002-12-06, 16:59:02

ちょっと脱線しますが、おもしろいので、モデル(情報を把握している人)を共有するワークスペースを作ってみましょうか。まず、今、開いているワークスペースのモデルを客観的(インスペクタやエクスプローラの助けなしに)に特定しなければいけません。これは、こんなコードでどうでしょう。
(ActiveWorld submorphs select: [ :mrph | mrph isKindOf: SystemWindow ]) first model
いい具合ですね。これを読み解きながらだと復習を兼ねていろいろと触れられそうだし。--sumim
- 2002-12-06, 17:29:15

>今、開いているワークスペースのモデルを客観的に特定
うぅぅ.何やらすごいコードが.print-itするとa Workspaceと出てきますね.頑張って読み解かなくちゃ.--人狼 - 2002-12-06, 17:32:57

ActiveWorld はインスペクトすると分かるように、クラスではなくインスタンスです。正体は(モーフとしての)デスクトップです。よく参照されるオブジェクトなので、同名のグローバル変数に束縛されてます。--sumim - 2002-12-06, 17:35:40

あとは雰囲気でなんとかなりますね(笑)。「オブジェクト メッセージ」書式のパターンにひたすら当てはめて、適宜、部分的に inspect-it しながらチャレンジしてみてください。--sumim - 2002-12-06, 17:38:18

>正体は(モーフとしての)デスクトップです
a PasteUpMorphと言うタイトルが出てきます.黒ハローと茶ハローのご説明の時に出てきましたよね.--人狼 - 2002-12-06, 17:40:08

そうすると、ActvieWorld submorphs は…。--sumim - 2002-12-06, 17:47:22

デスクトップのサブモーフのコレクションのコピーを返す…かな?--人狼 - 2002-12-06, 17:50:47

そうです。サブモーフの配列を返します。サブモーフたちを束縛した配列を作って(コピーして)返します。配列に対して送られるのは select: [ :mrph | mrph isKindOf: SystemWindow ] ですが、これはちょっと説明がいるかもしれませんね。引数のブロックは条件式を表わすメッセージ式で true か false を返すはずです。ループのたびに、mrph という偽変数に要素であるサブモーフを束縛し、ブロック内のメッセージ式を評価します。結果、true のものだけを集めて新しい配列を作って返します。--sumim - 2002-12-06, 17:57:47

>サブモーフの配列を返します。コピーはしません。
そうですか.コピーしないのですか.Morph >> #submorphs^ submorphs copyと,なっていたので,最後のcopyの解釈に困ってました.--人狼 - 2002-12-06, 18:00:09

いや、コピーでいいのです。サブモーフごとのコピーと勘違いしました。ごめんなさい。--sumim

select: についてたとえば、#($a $b $c $d $e $f $g) select: [ :item | item isVowel] なら、#($a $e) が返ります。--sumim - 2002-12-06, 18:02:47

もう時間ですね。旅の間、ちょっとじっくり悩んでみてください(笑)。--sumim - 2002-12-06, 18:05:00

>旅の間、ちょっとじっくり悩んでみてください
すみませんです.ちょっとじっくりと考えてきます.--人狼 - 2002-12-06, 19:49:59

ただいまです.昨日は羽田でエライ目に遭いました.今週は何やら忙しいみたいですので,先週までみたいに,スピーディーではないと思いますが,よろしくお付き合い下さい.--人狼 - 2002-12-10, 11:29:26

さて…
デスクトップのサブモーフを束縛した配列のコピーを返します.この配列の全要素について順次,その種類がシステムウィンドウであるかを検査し,システムウィンドウであるものだけの配列を生成します.
そのシステムウィンドウであるサブモーフだけを束縛した配列の先頭の要素のモデルを返しています.
これをprint-itするとa Workspaceとなります.ここで,常に先頭と決め打ちでワークスペースとなると言う保証があるのかは,まだ判りません.--人狼 - 2002-12-10, 11:29:38

昨日は羽田でエライ目に
たいへんでしたね。ご無事でなにより。--sumim
- 2002-12-10, 11:31:07

スピーディーではない
こちらこそ、よろしくお願いいたします。また〜りゆきましょう。--sumim
- 2002-12-10, 11:32:20

常に先頭と決め打ちでワークスペースとなると言う保証
これは、submorphs 列が動的(当たり前っちゃあ当たり前ですが(^_^;))で、サブモーフの前後関係とシンクロしている(こちらが言いたかった…)仕様を利用しています。例えば、矩形モーフにいくつかのサブモーフを追加して、矩形モーフのインスペクタで submorphs を覗いてみてください。例えば下図で、楕円をピックアップしてドロップすると、それが要素の先頭に移動することがわかります。--sumim
- 2002-12-10, 11:39:31

External Image

External Image

今、画面に見えているモーフはシステムウインドウを含めて、デスクトップのサブモーフなので、最前面にある、つまり編集中のワークスペースを一意に指し示すはずだということです。モーフとして最前面にあれば良かったのですが、どうやら場合によってはフラップのタブ類が最前面にきてしまうことがあるようなのでシステムウインドウに限りました。--sumim - 2002-12-10, 11:44:30

>ご無事でなにより。
有り難うございます.何とか帰って来る事が出来ました.--人狼 - 2002-12-10, 13:30:55

>また〜りゆきましょう
すみません,よろしくお願いします.--人狼 - 2002-12-10, 13:31:13

>サブモーフの前後関係とシンクロしている仕様
確認してみました.なるほど.そう言う理屈なのですね.有り難うございます.--人狼 - 2002-12-10, 13:31:28

>最前面にある、つまり編集中のワークスペースを一意に指し示すはず
ですね.上記の理屈が判ればこうなりますね.フラップのタブとの関係も了解です.--人狼 - 2002-12-10, 13:32:57

そう流れから外れるわけではありませんがやはり脱線して他に、今、タイプして入力中のウインドウを特定する方法はないか考えてみましょう。ここまでは「モーフとして見たときのデスクトップの、やはりサブモーフとしてのウインドウ」という側面からそれを返値として返すメッセージ式を考えてみました。他にアプローチの方法は思い付きそうですか? ヒントは、SystemWinodw のインスタンスであることがわかっている…という切り口と、GUI のフォーカス(つまりアクティブなウインドウはひとつ)の切り口とでも申しておきましょうか。ってそれってほとんど答えじゃん>われ(^_^;)。--sumim - 2002-12-10, 13:49:55

>SystemWinodwのインスタンスであることがわかっている
SystemWindowの配列を生成して,その2番目のモデルを取得する.と,言うのはどうでしょう?1番目はデスクトップになるので,最前面に出ているワークスペースが2番目かな…と.
SystemWindow allInstances second model
print-itしてみるとa Workspaceとなりました.GUIの方はまた後ほど調べてみます.--人狼 - 2002-12-10, 15:10:21

>1番目はデスクトップになる
ありゃ勘違い.デスクトップではなくて a Project(The Worlds of Squeak)だそうです>first model--人狼 - 2002-12-10, 15:31:46

そうですね。SystemWinow のインスタンスはあくまでシステムウインドウなので、デスクトップ(PasteUpMorph のインスタンス)は関係ありません。また、allInstances で返ってくる配列は、前後関係を反映されてないようなので一概に first、second …と簡単には特定できないのが難点です。そこで、SystemWindow クラスをブラウズしてみると、しきりに actviate や active… といったメッセージが目に付くことと思います。どうやらシステムウインドウは、自分がアクティブかそうでないかを判断する能力を持っているようです。そこで、こんなメッセージ式はどうでしょうか?
(SystemWindow allInstances select: [ :win | win isActive ]) first
--sumim
- 2002-12-10, 16:01:49

>SystemWinowのインスタンスはあくまでシステムウインドウ
はい,ここを勘違いしていました.失礼しました.
>allInstances で返ってくる配列は、前後関係を反映されてない
あぁ,そうなんですか.むぅ〜…まだまだ甘いですね>自分
>SystemWindowクラスをブラウズしてみると、しきりにactviateやactive…といったメッセージが目に付く
確かに目に付きます.なるほど,こう言う風にアプローチしていくのですね.ブラウズしていながら,そこに気付かないのは,まだまだ注意が足りないですね.提示頂いたメッセージ式は理解出来ました.--人狼 - 2002-12-10, 16:28:05

で、SystemWindow >> #isActive のソースを見てみると、最終的に == TopWindow というメッセージを自分に送ってアクティブかどうかを判断をしているようです。ちなみに、この == というメッセージセレクタですが、これは、レシーバに自分と引数が同一のオブジェクトかどうかを判断させてその真偽値を返します。ちなみに = は、そこまで厳密でなく、主観的に同じことを意味するオブジェクトなら true を返します。
'jinro' == 'jinro' copy
'jinro' = 'jinro' copy
#jinro == #jinro copy
#jinro = #jinro copy
文字列リテラル式は同じ内容の複数のインスタンスの存在を許すので1行目のメッセージ式だけ false を返しますが、他はすべて true を返す…という具合です。話を戻すと、どうやら TopWindow にアクティブウインドウが束縛されているようです。この大文字で始まる変数をクラス変数といいます。でも大文字だからクラス変数…というわけではなく、クラス変数(といくつかの広域変数)は大文字で始めることが推奨されているのでそう判断したまでで、もしかしたらクラス変数ではないかもしれません。そこで、クラス定義を確認すると(もしくは、class vars ボタンで現われるリストから)これが、SystemWindow に定義されているクラス変数であることが分かります。クラス変数は、クラスとそのインスタンスによって共有されいずれからもアクセス可能な変数です。--sumim
- 2002-12-10, 16:46:04

そこで、この TopWindow を素直に返すメソッドがあれば、一件落着…となるので探してみましょう。ブラウザの class vars ボタンで呼び出されるメニューから TopWindow を選択すると、TopWindow を参照、もしくは TopWindow にオブジェクトを束縛する手続きをとるメソッドが一覧できます。残念ながら、TopWindow をそのまま返すメソッドはないようです。ただ、クラスメッセージ(SystemWindow class に定義されたメッセージ)に TopWindow に言及するメッセージがあるようなので、念のため、SystemWindow class もブラウズしてみます。やはり TopWindow をそのまま返すメソッドは見当たりませんが、SystemWindow class >> #windowsIn:satisfying: というのがあります。どうやらこれは、条件判定用のメッセージ式を含むブロックを第2引数に添えて、第1引数のデスクトップ上で与えられた条件を満たすウインドウを列挙するメッセージのようです。そこで、先のメッセージ式も
(SystemWindow windowsIn: ActiveWorld satisfying: [ :win | win isActive ]) first
と、長くなったんだか短くなったんだかわからないけどとりあえず別の表現で記述できることが分かります。--sumim
- 2002-12-10, 17:02:28

しょうがないので、ないものは作ってしまえってんで、SystemWindow class >> #topWindow と次のように定義してしまうのも個人用とならアリかと。
topWindow
    ^ TopWindow
これで、SystemWindow topWindowと素直に書くことができます。--sumim
- 2002-12-10, 17:05:40

ここで禁じ手も学んでおきましょう。クラス変数もインスタンス変数同様、関係者(SystemWindow とそのインスタンス)以外から直接アクセスすることは推奨されていませんが、これをやってみます。SystemWindow をインスペクトすると、classPool というインスタンス変数があることに気が付きます。ここには、辞書が束縛されていて、#TopWindow というキーに、SystemWindow のインスタンスが束縛されていることも分かります。こいつにアクセスすれば、クラス変数の中身は簡単にゲットできそうです。インスタンスへのアクセスはたいてい同名のメソッドに定義されていますから、
SystemWindow classPool
を inspect-it してみましょう。どうやらビンゴのようで、SystemWindow のインスペクタで見たのと同じ辞書を得ることができました。当然と言えば当然で、すべてのメタクラスのスーパークラスである Class にきちんとこのことは記述されています(Class >> #classPool)。辞書に対しては、at: #キー というメッセージを送ることで、それに対応して束縛されているオブジェクトを得ることができます(Dictionary >> #at:)。まとめると、
SystemWindow classPool at: #TopWindow
で、TopWindow に束縛されているオブジェクトを参照できることになります。あくまで禁じ手ですが…。--sumim
- 2002-12-10, 17:14:36

すみません,時間がなかなか取れなくて.今週はどういう訳か忙しいです.--人狼 - 2002-12-11, 08:58:14

大変,ご丁寧にご説明頂き有り難うございます.どういうアプローチでTopWindowに辿り着いたか,そこから,どのようにメソッドを探求するか,実によくわかる例です.ご説明頂いた中に疑問点は無いと思います.--人狼 - 2002-12-11, 09:01:16

>ないものは作ってしまえ
これは,個人が自分の環境を便利にする為にやっているもので,再配布が目的ではないのなら,問題無いのですよね?--人狼 - 2002-12-11, 09:02:27

>禁じ手も学んで
禁じ手と言うからには,実装は出来るけれども,やらない方が良い,と言う風に考えるのが吉ですよね.ただ,深い世界を垣間見ると,こういう事なんだよ,と.--人狼 - 2002-12-11, 09:05:28

再配布が目的ではないのなら,問題無いのですよね?
ええ。問題ありません。ただ、自分用のチェンジセットなどを用意して、管理・把握しておく必要はあるでしょう。将来、配布したり共有するためのオブジェクトをこしらえているときに紛れ込んだり、それを前提とした仕組みを組み込んでしまうとやっかいなので。--sumim
- 2002-12-11, 10:26:46

実装は出来るけれども,やらない方が良い,
そうですね。使おうと思えば使えるけど、普段は使わない。悪い魔法を知らないと良い魔法も効果を持たないというのと似て…ないですね(爆。--sumim
- 2002-12-11, 10:29:14

さてモーフ的視点から、クラス-インスタンス的視点からときて、最後にもうひとつ、GUI 的視点からのアプローチを試してみましょう。ActiveHand というグローバル変数に束縛されている HandMorph のインスタンスは、いわゆるマウスポインタの役割りを果たしています。ActiveHand を inspect-it して、インスペクタから bounds を右ペインに表示させておくと、マウスポインタの動きに連動して bounds(表示矩形領域)がリアルタイムで変化することが分かります。ActiveHand には、ポインティングの他にもフォーカスを把握する機能があります。そこで、彼が把握している keyboardFocus から、今、編集中のテキストを含むシステムウインドウを特定できないか…というアプローチです。具体的には、ActiveHand keyboardFocus は、TextMorphForEditView というワークスペースなどの編集用のペインに特化されたテキストモーフを返すので、これのオーナーを辿ってゆけば、システムウインドウに行き着けるのではないか…ということですね。実際には、
ActiveHand keyboardFocus owner owner owner
と単純に辿ってもよいのですが、TextMorphForEditView は、editView にその編集枠モーフを束縛しているので、これを使って
ActiveHand keyboardFocus editView owner
でシステムウインドウにたどり着くことができます。--sumim
- 2002-12-11, 10:43:19

今週はどういう訳か忙しいです.
なるべく負担にならないような内容展開にして勝手に進めますので、適当に合いの手を入れてください(笑)。もし興味があって、でも時間がなくてじっくり考えたいけどそれがままならないときは、ノーティファイアを出していただければそこいらへんで止まっておきます。--sumim
- 2002-12-11, 10:45:47

HyperTalk や AppleScript では「このカードのこのフィールド」「このウインドウのこのボタン」という具合に、ユーザーが見たままを素直に書き下すことで客観的に参照できるように、そのためのフレームワークが整備されています。しかし、Squeak には「これここに見えているこのモーフを…」ということがしにくいです(インスペクタでの self 参照を除外すれば、できてもせいぜいワークスペースへのドロップインによるワークスペース変数作成機能程度)。目に見えて特定できるモーフも、やはり、論理的にその特徴から候補をしぼってゆき特定する必要があります。モーフ/プレイヤをそれに付けた名称で簡単に参照できる機能を付加することはそれほど難しいことではないと思うのですが、それがいいことなのか悪いことのかは、私自身もちょっとまだ判断できていないのでここでは言及のみに留めておきます。--sumim - 2002-12-11, 11:36:23

>管理・把握しておく必要はあるでしょう
おっしゃる通りですね.自分だけの閉じた世界だけなら問題無いのでしょうが,「将来ずっと閉じている」と言う保証が出来ない以上は,管理しないと他の方に迷惑をおかけしますね.留意します.--人狼 - 2002-12-11, 13:06:47

>使おうと思えば使えるけど、普段は使わない
何やら危険な兵器のようですな.
>悪い魔法を知らないと良い魔法も効果を持たない
そこに手段として存在していて,使っちゃいけないんだけど,あるから万が一の場合にも大丈夫.A兵器みたいで怖いっす.--人狼 - 2002-12-11, 13:09:03

>GUI 的視点からのアプローチを試してみましょう
う〜ん,こうやってアプローチするのですね.マウスポインタとは予想しておりませんでした.フォーカスを特定する事ばかり調べていました.--人狼 - 2002-12-11, 13:11:46

>負担にならないような内容展開にして勝手に進めます
ご配慮頂き有り難うございます.助かります.
>ノーティファイアを出して
えっと…ノーティファイアの画像のスクリーンショットを取らなくちゃ(汗)--人狼 - 2002-12-11, 13:13:00

>いいことなのか悪いことのか
難しいテーマですね.私見ですが,名称による参照(=オブジェクトの特定)は悪いことだと思っています.それは,昔々のオブジェクトによらないプログラミング環境の時代の遺物ではないかと.オブジェクト指向の世界では,オブジェクトはその種類と関係性においてのみ存在を特定されるべきではないかと思っています.オブジェクトに名称を付与し,その名称にて他のオブジェクトから参照される時,それはオブジェクト間の関係ではなく,名称により縛られている事になると思っています.そうする事によって,オブジェクトのポータビリティが下がりそうな気がするのですが…考えすぎでしょうか?--人狼 - 2002-12-11, 13:19:17

私見ですが,名称による参照(=オブジェクトの特定)は悪いことだと
なるほど、ポータビリティですか。おもしろい観点ですね。ちなみに SqueakToys なんかは、名前(のパネル)で参照できるので、そういう HyperTalk、AppleScript 的なお手軽さを求めるなら、Squeak でも SqueakToys を中心に使え…ってことになるのでしょうかねぇ…。よく分かりません。--sumim
- 2002-12-11, 13:56:38

さて、話を「モデルを共有するワークスペースを作って、その動きをみてみる」に戻しましょう。今、まさに do-it せんとしているテキストを編集しているワークスペースの特定のしかたはいくつか分かったので、これと同じモデルを使って新しいワークスペースを作ることにします。まず、ワークスペースがどのように作られているか知りたいので、デスクトップメニュー → open... サブメニューを開き、workspace のメニュー項目をモーフとして選択します。cmd-クリックを2回してもいいですし、shfit-cmd-クリックで一発選択するのもよいでしょう。選択できたら、灰色ハローを shfit-クリックしてインスペクタを開きます。--sumim - 2002-12-11, 14:03:16

External Image

External Image

ここで、target、selector、argumetns を見ると、このメニューコマンドが誰にどんなメッセージを送るためのものかを知ることができます。細かい説明は省きますが、ここでは最終的に(デスクトップメニューに)openWorkspace というメッセージを送っていることが推察されます。openWorkspace をブラウズすると Workspace のインスタンスを作って、openAsMorphLabel:inWorld: を送っているようです。実際、
Workspace new openAsMorphLabel: 'Jinro' inWorld: ActiveWorld
で確かに新しいワークスペースが開きます。--sumim
- 2002-12-11, 14:13:40

ただ、これでは新しいモデルが割り当てられてしまう(そもそも手持ちの Workspace のインスタンスを使いたいのに Workspace new としている時点で駄目(^_^;))ので、openAsMorphLabel:inWorld: にダイブして、ワークスペースがどのように作られているかをもうちょっと調べてみる必要がありそうです。--sumim - 2002-12-11, 14:17:16

で、openAsMorphLabel:inWorld: にダイブ(openWorkspace のメソッドを表示しているブラウザで implementors ボタンから openAsMorphLabel:inWorld: を選択)してみると、
openAsMorphLabel: labelString  inWorld: aWorld
    "Workspace new openAsMorphLabel: 'Workspace'"
    | window |
    window _ (SystemWindow labelled: labelString) model: self.

    window
        addMorph: (
            PluggableTextMorph 
                on: self 
                text: #contents 
                accept: #acceptContents:
                readSelection: nil 
                menu: #codePaneMenu:shifted:)


        frame: (0@0 corner: 1@1).

    window openInWorld: aWorld
と、ちょっと見やすく改行位置を変えていますが、こんなコードになっています。システムウインドウを作り、そこに新しく作った PluggableTextMorph のインスタンス(new していませんが、on:text:accept:readSelection:menu: にダイブすると分かります)をサブモーフ化して、両者でモデル(Workspace のインスタンス、この場合 self に束縛されている)を共有しているようです。この、self 部分を好きなものに変えてしまえば、モデルを共有する別のワークスペースを作ることが簡単にできそうですね。--sumim
- 2002-12-11, 14:28:32

で、こんなの
| window currentWindow |
currentWindow _ ActiveHand keyboardFocus editView owner.
window _ (SystemWindow labelled: currentWindow label) model: currentWindow model.
window
    addMorph: (
        PluggableTextMorph 
            on: currentWindow model 
            text: #contents 
            accept: #acceptContents:
            readSelection: nil 
            menu: #codePaneMenu:shifted:)
    frame: (0@0 corner: 1@1).
window openInWorld
ができました。--sumim
- 2002-12-11, 14:32:20

選択して do-it で、spawn 時(cmd-o)と似た新しいウインドウが開きます。内容は同じでも新しいモデルを持ったウインドウを作る spawn と違うのは、元のウインドウとモデルを共有しているので、例のパッチを当てていれば、cancel すると、両者(do-it したウインドウと、新しく表示されたウインドウ)で最後に accept した内容が呼び出されることです。--sumim - 2002-12-11, 14:35:58

>確かに新しいワークスペースが開きます
確かに.このように推察して,試してみれると言うのが面白いですね.--人狼 - 2002-12-12, 09:44:47

>self部分を好きなものに変えてしまえば
いやいや.言われてみれば確かにその通りなのですが(汗)ここまで読み取れてないです.う〜ん.--人狼 - 2002-12-12, 09:50:37

で,提示頂いたソースをdo-itした物とspawnした物を比べてみました.なるほど…--人狼 - 2002-12-12, 09:51:38

明日は比較的時間に余裕がありそうなので,ソースを解読してみたいと思います.--人狼 - 2002-12-12, 13:23:43

ええ。是非。でもあまりご無理はなさらないように。--sumim - 2002-12-12, 14:07:15

一時変数windowcurrentWindowを宣言.
currentWindowにWorkspaceを束縛.
labelled:セレクタがWorkspaceのラベルを引数に取ってSystemWindowに送信される.→
model:セレクタがWorkspaceのモデルを引数に取って辺値である新しいSystemWindowにに送信される→
この辺値である新しいSystemWindowが一時変数windowに束縛される.
#ここで,新しいSystemWindowのモデルとWorkspaceのモデルが共有された.
addMorph:frame:セレクタがPluggableTextMorphのインスタンスと(0@0 corner: 1@1)を引数に取って新しいSystemWindowに送信される.
#ここで,新しいSystemWindowにWorkspaceが備えるPluggableTextMorphをサブモーフ化している.
最後に新しいSystemWindowをWorld(デスクトップ?またはプロジェクト?)のサブモーフとして完了.

だと思うのですが…addMorph:frame:の引数の解読まで至っておりません.--人狼 - 2002-12-13, 11:04:51

問題なさそうですね。PluggableTextMorph は奧が深いので、タイトルバーや枠(だけ)を提供するシステムウインドウにサブモーフとして組み込まれるテキストフィールド…程度にとらえておいていだければよろしいかと思います。通常のサブモーフ化では、addMorph: で事足りるのですが、システムウインドウの場合、addMorph:frame: というメソッドを特別に用意して、その第二引数でサブモーフ(おそらくウインドウ内のパーツとなるモーフ)をどのくらい内輪よりに配置するか…ということも同時に決められるようになっているみたいですね。--sumim - 2002-12-13, 12:25:03

>PluggableTextMorphは奧が深いので
はい,了解しました.深い内容は,それが必要になった時に学習します.
>システムウインドウの場合、addMorph:frame:というメソッドを特別に用意して
なるほど.addMorph:も調べてみました.--人狼 - 2002-12-13, 13:02:16

えっと、どこからでしたっけ。あ、そっか。モデルで遊んでみましょうってとこから脱線したんですね。このモデルにワークスペース変数(とそれに束縛されているオブジェクトの対を収めた辞書)が格納されている…という話でした。--sumim - 2002-12-13, 14:22:45

で、create textual references to dropped morphs オプションが設定されているワークスペースでは、モーフをドロップインするとそのモーフを適当な名前のワークスペース変数に束縛すると…。こういう仕組みです。--sumim - 2002-12-13, 14:24:56

なので、ドロップインした rectangleXXX などという変数にメッセージを送るメッセージ式を記述することで、その変数に束縛されているモーフにメッセージを送ることができるわけです。--sumim - 2002-12-13, 14:26:29

モデルで遊んでみましょう
えぇ,そうだったみたいです.既にそっちは忘れて,こっちに熱中しちゃってました.--人狼 - 2002-12-13, 14:27:25

>そのモーフを適当な名前のワークスペース変数に束縛する
なるほど.適当な名前のワークスペース変数を用意して,そこにドロップされたモーフを束縛して,変数名を表示してくれているのですね.--人狼 - 2002-12-13, 14:30:42

>変数に束縛されているモーフにメッセージを送る
そう言う事になりますよね.
ところで,最初の頃に他の言語の感覚から「変数に代入」と言うような事を申し上げましたが,ここ最近教わった内容を考えるに,「他の言語で言うところの変数と言うよりも,オブジェクトを名前で参照と考えた方が良い」とおっしゃって下さった意味が判ります.--人狼 - 2002-12-13, 14:37:34

で、たしかに Workspace の drop なんたらって感じのメソッドをつらつらと眺めていると確かにそんなことをしていそうなの( Workspace >> #acceptDroppingMorph:event:inMorph: )が見つかります。
acceptDroppingMorph: dropee event: evt inMorph: targetMorph 
  "Return the dropee to its old position, and add a reference to it at the cursor point."
  | bindingName |
  bindingName _
    (dropee externalName translateToLowercase, dropee identityHash printString)
      asIdentifier: false.
  targetMorph correctSelectionWithString: bindingName, ' '.
  (self bindingOf: bindingName) value: dropee.
  dropee rejectDropMorphEvent: evt.
  ^ true "success"
…のように(例によって改行位置を変えています)。変数名は hoge だって hage だって構わないので、このメソッドを
acceptDroppingMorph: dropee event: evt inMorph: targetMorph 
  "Return the dropee to its old position, and add a reference to it at the cursor point."
  | bindingName |
  bindingName _
    ('hoge', dropee identityHash printString)
      asIdentifier: false.
  targetMorph correctSelectionWithString: bindingName, ' '.
  (self bindingOf: bindingName) value: dropee.
  dropee rejectDropMorphEvent: evt.
  ^ true "success"
に変えてしまえば、たしかに hogeXXX のようになります。--sumim
- 2002-12-13, 14:41:27

>オブジェクトを名前で参照と考えた方が良い」とおっしゃって下さった意味が判ります.
なによりです。オブジェクトの生き死(有り体に言えばメモリの解放)に意識が向かうようになると、束縛…というニュアンスのほうもつかめてくると思います。--sumim
- 2002-12-13, 14:46:38

HTML の制限から変えた場所を明示的にできませんが、こういうとき、cmd-C を使ってください(ゎ。--sumim - 2002-12-13, 15:04:39

>たしかに hogeXXX のようになります
たしかに.と,言う事でdropeeと言うのがドロップされたモーフのインスタンスを束縛する偽変数でしょうか?externalNameと言うのは外部名称とでも訳すのでしょうか.そのモーフが何であるかを知る為の名前を得るためのメッセージですね.identityHashはそのモーフを識別する為のハッシュのようなものを得るためのメッセージですね.これは,モーフ毎に一意であれば良いのかな?SmallInteger以外でのオーバーライド禁止となっていますね.--人狼 - 2002-12-13, 15:06:59 赤字はsumim

>束縛…というニュアンスのほうもつかめてくる
頑張りますp(^^)q--人狼 - 2002-12-13, 15:09:37

>cmd-C を使ってください
なるほど.こう言う風に使うと便利ですね.あ,これもWorkspaceなんだ.--人狼 - 2002-12-13, 15:10:18

>モーフ毎に一意
私は不勉強でよく知らないのですが、このハッシュを使ってオブジェクトは同一かそうでないか(==)を調べている場合が多いですね。--sumim
- 2002-12-13, 16:09:37

>dropeeと言うのがドロップされたモーフのインスタンスを束縛する偽変数でしょうか?
Morphic フレームワークに分け入ることになるので注意深く辿らなければなりませんが、sendors-of-it でメソッドと遡ってゆくと、そうであることが分かります。また、具体的にどういう機能を持つかは分かりませんが、リストペイン(PluggableListMorph のインスタンス)もドロップインすると何かを起こしそうな雰囲気がありそうですね。(←これは調べろ、ということではなく単に純粋なコメントです)--sumim
- 2002-12-13, 16:15:43

>ハッシュを使ってオブジェクトは同一かそうでないか
そうですか.そう言う使い方もされているのですね.ProtoObject >> #identifyHashのコメントを読むと,確かに「レシーバーの識別」と言う事ですから,有用のようですね.--人狼 - 2002-12-13, 16:29:54

>sendors-of-itでメソッドと遡ってゆく
確かにそうですね.この位は自分で調べないとだめですね.すみません(汗)
>リストペイン(PluggableListMorphのインスタンス)
こちらは,PluggableTextMorphに比すると,3行ほど処理が多いですね.この内容ついて考えてみるのは今の私にはまだ辛いかな(笑)--人狼 - 2002-12-13, 16:36:49

>この内容ついて考えてみるのは今の私にはまだ辛い
「ちょっと今は無理だな…」ってメソッドは深く追求せず、その存在だけを頭の片隅においておくと、あとでいろいろ見えてきたときに「そういえば…」と引き返して来れて楽しいです。--sumim
- 2002-12-13, 16:43:14

>「そういえば…」と引き返して来れて
そうですね.それは楽しいと思います.今も従前sumimさんがおっしゃっていた事が一つ一つ意味が見えたり,理解が深くなったりと言うのが楽しいです.--人狼 - 2002-12-13, 16:58:09

トラップも仕掛けがいがあるというものです(ゎ。さて、次は(どの?<ぉぃ!)assuredPlayer もしくは player ですが、これは前も整理していただいたのでもんだいないですね。スケッチ以外はビューワを開くまではプレイヤがないので、assuredPlayer のほうを使う必要があります。ので、安全のため assuredPlayer を常用しておくのが吉かと。--sumim - 2002-12-13, 17:10:44

>トラップも仕掛けがいがある
毎度,ちゃんとそのトラップにはまってるんですよね.困った事に(笑)
>スケッチ以外はビューワを開くまではプレイヤがない
すみません,確認を.ここで言う「ビューワ」とは?--人狼 - 2002-12-13, 17:18:08

ん? ビューワって他にも出てきました? 水色ハローで表示されるフラップで情報一覧と遠隔操作とスクリプト用パネル生成用パレットを兼ねたものです。上の search で“ビューワ”をキーワードにして検索すると出てくるはずです。--sumim - 2002-12-13, 17:22:32

>水色ハローで表示されるフラップ
あ,そうでした.失礼しました.--人狼 - 2002-12-13, 17:29:24

>安全のためassuredPlayer を常用しておくのが吉
は,スケッチはassuredPlayerもしくはplayerで良いけれども,スケッチ以外はassuredPlayerでなくてはならないので,assuredPlayerを使う方が吉と言う事ですね.--人狼 - 2002-12-13, 17:31:04

そうです。--sumim - 2002-12-13, 17:37:56

了解しました.--人狼 - 2002-12-16, 11:32:11

AC04 やりました。楽しいですね、これ。こんど対戦しましょう!--sumim - 2002-12-16, 12:14:41

おぉっ!お気に召しましたか>AC04!是非対戦させて下さい!(って,私がぼろ負けでしょうが(^^;)--人狼 - 2002-12-16, 12:47:23

黄色が落とせねぇなぁ…と思って攻略本を見たら、なんとあいつら静止して向きを変えるという反則技を使っているんだそうですね。勘弁してよって感じで読み進めると、なんと、止まったときにむにゅむにゅすると簡単に撃墜できる…というなんともおそまつな(^_^;)。「モビルスーツの性能の差が戦力の決定的差でないことを教えてやる」と粋がってデフォの機体でどこまでいけるかチャレンジしましたが、海岸線の攻略(09 面?)でどうしても時間が足りなくて断念して F-16 に乗り換えました(T_T)。タイム制限にはちょっと辟易としています。この点は ENERGY のほうがまた〜りできていいですね。F-16 に関して言えば、やっぱり乗り慣れた(ぉぃ!)機体は最高っすなぁ(笑)。そうそう。プレイ後の映像にちょっと手ぶれ効果をいれただけでえらくかっこよくなっていますね。なんで ENERGY AIRFORCE もこれにしなかったなんだろう…。--sumim - 2002-12-16, 12:53:54

>静止して向きを変えるという反則技
そうなんですよ.最初は泣かされました.止まったときにむにゅむにゅは(汗)そのくらいの隙を見せてあげないと,撃墜は難しいのですよ>黄色.後にQAMM等と言う都合の良いミサイルが使えるようになるまでは,なかなか落とせません.と,言っても仮想機体のX-02とQAMMは無敵過ぎて面白くないのですが(苦笑)--人狼 - 2002-12-16, 13:05:04

>デフォの機体でどこまでいけるかチャレンジしました
F-4でですか.それはすごい.F-4で8面までクリアと言うのは素晴らしいです.恐れ入りました.時間制限は,たしかに鬱陶しいのですが,ENERGYとはミッションの性格が異なるので,これはこれで「こう言う世界なのだ.」と割り切ってしまってます.リプレイの映像はかっちょい〜っすね.そうそう,NORMALから始めて,HARD,ACE(あれ,もう一つあったな,上に)と上り詰めてくださいね.一番上のランクだと被弾一発即撃墜ですよ♪--人狼 - 2002-12-16, 13:08:12

>一番上のランクだと被弾一発即撃墜
ENERGTY のミサイルの自機へ当たりやすさもゲームとしては異例ですが、AC04 の当たりにくさもご愛敬ですね(笑)。あれなら、一発もしくは 1.5 発撃墜くらいがちょうど良いかもしれません。必至に避けようというモーティべーションがでるってもんです(笑)。もっともそのためにはロックオンや発射アラートを ENERGY なみにしてもらえないと怖いですが(^_^;)。--sumim
- 2002-12-16, 13:22:15

>AC04の当たりにくさもご愛敬
あはは(汗)いや,あれはあれでい〜んです(ほんとか?)AC04は熟練のシミュレーションプレイヤには物足り無いでしょうが,あのくらいでなければ,若手(ってなんだ?)が育ちません(苦笑)実際,10面以降は「飛行機はそんな事はしねぇよ」って言うツッコミどころ満載です(爆)AC04はアーケード系,ENERGYはリアル系と言う事でご容赦ください.--人狼 - 2002-12-16, 13:28:08

>F-4で8面までクリアと言うのは素晴らしいです
お褒めにあずかり光栄です。ノーマルで、F-16 に乗り換えてもまだストーンヘンジを壊したところまでなんですが…(^_^;)。次の夜の市街戦がやっぱり時間制限もので、時間を気にしながらちまちま点数稼ぐのがやんなっちゃってやめちゃいました(笑)。--sumim
- 2002-12-16, 13:28:37

>まだストーンヘンジを壊したところ
いや,それは全然「まだ」ではないです(汗)「もう」壊したですか>ストーンヘンジ.さすがですねぇ.いや,ほんとに対戦しても勝ち目が無さそうなんですが.夜の紫外線市街戦ってミッション15ですか?解放でしたっけ?もうクリア直前じゃないですか.これは,やはり難易度最高までと,隠し機体全取得を目指してください(汗)
sumimさんと対戦する時は私はX-02でないと勝てないかも(大汗)--人狼 - 2002-12-16, 13:50:37

>私はX-02でないと勝てないかも(大汗)
へえ…、そんなに強いんですか。>X-02 ちょっと乗ってみたくなったかも。--sumim
- 2002-12-16, 15:21:21

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


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

This page has been visited 2714 times.