187 | kis00283 | ひゅう | 1995/11/05 18:18:41 |
前へ
後へ
上へ
|
fkiss
180へのコメント
yavさんども。
| >・イベントが同時に発生したときの処理の優先順位は?
| 全て同時に処理される!!
これは参った!!(笑)
でも,将来 GS規格とするなら,
処理系依存ではなく,
できれば処理順を定義しておいてくださいね。
データ作者は自分の環境の KISSローダーで動作確認するだけ
ってことが多いので,
あいまいな記述に気がつかないでしょうから。
ちなみに,CNF記述の前の行から順に処理 ってだけでは不十分です。
実行中のコマンドによって新たなイベントが生じる可能性がありますから,
( moveコマンドで inイベントが発生したり… )
その場合,新たなイベントを優先するかどうかも決めなきゃいかんです。
| fkissは,実はKISSと固定値の解釈が違います!!
| というか,固定値に関してより深い解釈をとりいれてます.
これ!上手い方法ですね!
けっこう感動しました。
てっきり 999が特別な数字かと勘違いしてたんですが,
それは,調査に使ったデータの最大固定値が 999だっただけのようです。
yavさんのこの方法は奇麗だと思います。
| マウスのボタンの状態と生成されるイベントについてまとめてみます.
(訂正した方を)見せてもらいました。
いちおう,私の理解通りだったようです。(たぶん)
| > イベントはできるだけ排他的にした方が,
| > 細かい制御ができますし,
| > 処理順の問題も起きませんから。
| というのが,まさに正解だろうと思います.
これも,GSにするなら,
排他的な方がいいと
あらためてお願いしておきます。
| 実は,catch(123)と書くと,セル番号123と勘違いするのです.
| 単にセル番号でも指定できるという現在の内部的な都合でして,
| ""は外しても問題ないと思います.はい.
あらら,そんな裏技(?)があったからなんですね。
| > また,重なってる判定は,
| 当然,非透明部としてとらえるしかないでしょう.
| それ以外はデータ製作者に理解してもらえないだろうと思います.
なるほど,たしかにそうですね。
私もできる限り 非透明部 であって欲しいです。
インプリメント上の都合はよくわかんないですが,
スピードを(あまり)落とさずに実現できるもんなんでしょうか?
そのへんがちょっと心配。
まぁ,きっと可能だからこうおっしゃってるんでしょうね。
| あるセルがあるセルの完全に内側になったらとか
| 少しでも外側になったらイベントが発生するといった感じでいいかなと思っています
.
これなんですが,
(私が仕様を勘違いしてるかもしれませんが)
ちょっと不満があります。
完全に内側ってのはめったに使わない気がします。
で,ちょっとでも重なったら…ですが,
こんな場合はどうでしょう。
# 以下,条件分岐や変数は導入される事を前提としています。
リーヤ君(人間型)をドラッグしてて,
チャチャ(とちょっとでも重なって)ドロップすると狼(笑い顔)になり,
マリンちゃんにドロップすると狼(泣き顔)になる。
その他の場所にドロップした場合や,ドラッグ中は人間姿とする。
これを実現しようとすると,
;@in(リーヤ,チャチャ) f=1;
;@in(リーヤ,マリン) f=2;
;@drop(リーヤ) if (f==1) リーヤセルを狼(笑い顔)に変更
else if (f==2) リーヤセルを狼(泣き顔)に変更
のようにフラグが必要になってしまいます。
次のようにやりたいです。
例えば,istouch(A,B)として AとBがちょっとでも重なっていたら,
真を返すとして,
;@drop(リーヤ) if istouch(リーヤ,チャチャ) 狼(笑い顔)に変更
else if istouch(リーヤ,マリン) 狼(泣き顔)に変更
みたいにしたいです。
これとは別に,オブジェクトをドラッグするたびに呼び出されるイベント
が欲しいです。ここで istouchを使えば,in よりももっと
細かな制御ができますから。
#処理速度の点がちょっと気になりますが。
| > まず, goto は絶対必要だと思います!
| 処理に順番がないというかprologのような関数型言語を考えていたので,
| gotoは意味を持ちません!(またまた驚いたでしょ?)
Prolog…っすか?
う〜ん,あたしゃ Prologは随分前にちょっとやっただけなので
あんまりよく知らないですが,LISPなら結構やってます(これも随分前ですが)
いまの fkiss記法ってあまり関数型言語にゃ見えないけど… ^^;
どっちにしろ,逐次型実行を許す以上,gotoはあっていいと思います。
一般には,
gotoがあると,ソースの文脈を追いにくくなるので,
構造化,あるいは関数化し,
例えば,loop は 構造的言語なら while等 にして,
関数型言語なら再帰呼び出しにして,わかりやすくしてるだけだと思います。
KISSの CNF記述に,そんな大がかりなものは作らないでしょうし,
再帰呼び出しするわけではないので,
特に,関数型言語にするメリットがあまり見えないんですけど…。
それと,関数型言語にするなら,局所変数が無いと意味が
無いと思うんですけど,そこまでやる必要はないと思います。
せいぜい,固定数(256個とか1024個)のグローバル数値型変数で十分でしょ?
個人的には,CNF書式は,
オブジェクト指向っぽい記述がいいと思います。
今の,
;@イベント(オブジェクト) コマンド(オブジェクト)
;@ コマンド(オブジェクト)
;@ …
;@イベント(オブジェクト) コマンド(オブジェクト)
ではなく,
;オブジェクト
; イベント コマンド コマンド …
; イベント コマンド コマンド …
こういう形の記述の方が適してると思います。
コマンドは,デフォルトでオブジェクトに対して実行されるのです。
別に,カプセル化だとかそんなことは全然関係ないのですが,
イベント依存な動作を記述する場合は,
このほうが奇麗にかけます。
それと,セル名等を何度も記述する手間が減ります。
(個人的には,セル名を直接指定するのはイヤです)
この辺の事は,まとめてメールしようと思ってたんですが,
( 個人的に CNF記述案とかも考えたんですが )
ちょっと時間無くてまとまんないので,
よかったら,F.Kさん経由で,私の某所の書き込みを見てください。
fkiss規格及びそのGS化に関しては,期待しています。
〜 ひゅう 〜