Scratch 3.0 への提案

syokaki

賛成です。

yui0321

異論なし

sakai12

inoking wrote:
#8831 を基に
以下を反映したいと思います。
日本時間 2/7 20:00 までに特に異論なければ合意が取れたものとします。
1 → 却下
9 → 3種とも異論のない提案
10 → 却下
12 → 却下
16,17 → 却下

2, 11 は却下でいいですか？
これも異論がなければ反映します。

ここにないものは反映しないってことですか？

hirayuu1414

#8845
今後議論します。書いてあるものは真偽値型のブロックです。

Ke0

MitchyRoad wrote:
反対
15(もう実装されているため)と19と20(条件付きだは賛成)以外は全部賛成です。
20は条件付き賛成ですけど、最初にxとyのサイズを選ぶのが良いと思います

と言うことは現時点では9のみ「異論のない提案」ですが、それ以外の真偽値ブロックも全て追加すべきと言うことですか？

hhayyatto

「クリックされている」は必要だと思います。
初心者に優しいのがScratchであると考えてます。

hirayuu1414

#8844
15,20についてはまだ話していません。

yuzupon1133-sub

すいません、「クリックされている」というブロックは仕分け提案にないです。

Last edited by yuzupon1133-sub (Feb. 7, 2022 08:21:04)

sakai12

<このスプライトがクリックされた::sensing>

のことでは？

inoking

Ke0 wrote:
MitchyRoad wrote:
反対
15(もう実装されているため)と19と20(条件付きだは賛成)以外は全部賛成です。
20は条件付き賛成ですけど、最初にxとyのサイズを選ぶのが良いと思います
と言うことは現時点では9のみ「異論のない提案」ですが、それ以外の真偽値ブロックも全て追加すべきと言うことですか？

私は #8837 には関係ない話と解釈しました。

inoking

hhayyatto wrote:
「クリックされている」は必要だと思います。
初心者に優しいのがScratchであると考えてます。

10.

<このスプライトがクリックされた::sensing>

のことであれば #8831 をふまえてお願いします。

10は ST に却下されているイベントの検出
<[メッセージ v]を受け取った:: events>
と本質的には同じです。
イベントとは状態の変化です。真偽値では原理的に代用できません（イベントが既に発生したことは検出可能ですが）。

hhayyatto

<[メッセージ v]を受け取った:: events>

↑は「trueになるタイミングが曖昧」という理由で却下されていますが、こちらの方はそれほど曖昧ではありません。
それと「すでに発生したことが検知可能」なら、「クリックされるまで待つ」のようなものはOKですか？

sakai12

これを提案した方々は

<> まで待つ

<> まで繰り返す

end

ずっと
もし <> なら 
  
でなければ

end
end

に組み入れたかったのでしょう。

Last edited by sakai12 (Feb. 7, 2022 11:28:46)

hirayuu1414

#8853
いいえ、こちらも曖昧だと思います。

このスプライトがクリックされたとき

というのは、極端な話、

[クリックされた v] を受け取ったとき

と本質的には全く同じです。

syokaki

[メッセージ1 v]を受け取るまで待つ ::control

[メッセージ1 v]を受け取るまで繰り返す {} ::control loop

は却下されていないはずです。

Last edited by syokaki (Feb. 7, 2022 11:54:09)

Ke0

それは

<[メッセージ v]を受け取った:: events>まで待つ

とどう違うのですか？

inoking

syokaki wrote:
[メッセージ1 v]を受け取るまで待つ ::control

[メッセージ1 v]を受け取るまで繰り返す {} ::control loop
は却下されていないはずです。

そのとおりです。

Ke0 wrote:
それは
<[メッセージ v]を受け取った:: events>まで待つ
とどう違うのですか？

同じですが

<[メッセージ v]を受け取った:: events>

だけを取り出しても無意味ということです。

メッセージの受け取りについて以前この辺でも話がありました。

一般に、「イベント」は同期と呼ばれる処理の一つですが
これを操作する手法は大体決まっています。
「同期イベント API」などと検索すると多数ヒットします。例えば

[メッセージ1 v]を受け取るまで待つ ::control

は Win32 の API では WaitForSingleObject() に当たります。

hhayyatto

であれば

<このスプライトがクリックされた::sensing>

を却下し新たに

クリックされるまで待つ::control

を仕分け前に入れる、というのはどうでしょうか？

inoking

クリックされるまで待つ::control

は提案としてはアリですが、そもそも

このスプライトがクリックされたとき

では何がいけないのでしょうか？

イベントハンドラーではなくどうしてもメイン処理に書きたいということなら
以下で十分な気がします。

このスプライトがクリックされたとき
[変数 v] を (1) ずつ変える

[変数 v] を [0] にする
<(変数) > (0)> まで待つ

もし

クリックされるまで待つ::control

を追加するなら
すべてのイベント、メッセージ系ブロックに対して

～まで待つ::control

を追加しないと整合性が取れず、制御ブロックの種類がさらに増えてしまします。
それこそ「初心者に優しくない」と思います。

Last edited by inoking (Feb. 8, 2022 03:16:33)

AI_tachi

((1)(2) 番目（ [二次リスト v] ） :: list)

これって提案されていますか?

Discuss Scratch