Scratch への提案

Yellow_Apple

Last edited by Yellow_Apple (March 23, 2022 04:25:40)

hirayuu1414

そろそろ仕分けを進めましょう。

①かつとまたはの変換
反対と言っている人は提案内容を誤解していそうです。

<<条件1> かつ <条件2>>

を右クリックかなんかで

<<条件1> または <条件2>>

に変換できるようにすると言う提案です。
それを踏まえて意見を出してもらえないと判断ができません。

②

<[文字列] は大文字 ::operators>

大文字と小文字が混ざっているときに疑問と言う人が多いです。
4は話し合うまでもなく異論なしでしょうし、こっちは却下で良いでしょう。

③

(()の()乗::operators)

代用方法は難しく、誤差が出るため、あっても良いと言う意見が目立ちます。
これは異論なしでも良さそうです。

④

<[] と [] が大文字小文字を含めて同じ::operators>

こちらはだいぶ前から英語のトピックで提案されているため、話し合うまでもなく異論なしです。

⑤

(もし <> なら [] でなければ [] :: operators)

プログラムがスッキリさせられる、演算に「もし」があると混乱する、使わない、など意見がかなり分かれていました。
意見が分かれるでしょう。

⑥

<TRUE::operators>

<FALSE::operators>

これは、プログラムをすっきりさせられる反面、簡単に代用できます。
こちらも意見が分かれるでしょう。

⑦

([ v]をunicodeで[デコード v]::operators)

使用用途がない、チャットの作成を助長させると言う意見が目立ちました。
却下で良いでしょう。

⑧

([]を計算::operators)

https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2839913/
計算はブロックでやるべきと言う意見がかなり多いです。
こちらも却下で良いでしょう。

⑨ ⑩

<[] ≦ []::operators>
<[] ≧ []::operators>
<[] ≠ []::operators>

代用可能と言っている人と、代用が難しいと言う意見に分かれていました。
意見が分かれるでしょう。

Last edited by hirayuu1414 (March 23, 2022 05:12:50)

newmomizi_txt

①かつとまたはの変換
あくまで個人の意見ですが、いらないように感じます。
2つを間違えることはそうそう無いですし、通常の方法での修正も容易です。
修正が面倒なほどのプログラムを組むような人は、その手のアドオン等を使っている人も多いのでは無いでしょうか。

②

<[文字列] は大文字 ::operators>

どれか一つでも大文字ならtrue(OR的思想)なのか、全部大文字(AND的思想)なのかが分かりづらいですし、
4があれば代用も簡単なので、必要ないと思います

③

(()の()乗::operators)

対数や繰り返しを使った代用は、前者は誤差の問題、後者は整数のみの制限があるため、代用は難しいと判断しました。
賛成です

④

<[] と [] が大文字小文字を含めて同じ::operators>

言うまでもなく賛成ですね。コスチューム代用の方法は面倒ですし、100%penなどにも使う事ができないと聞いた事があります。

⑤

(もし <> なら [] でなければ [] :: operators)

制御ブロックと変数を使った代用方法もありますが、変数の管理やプログラムがごちゃごちゃになる問題もあります。
ですが、これがあった場合のメリットも少ないように感じます。
私は「どちらかといえば反対」程度です。

⑥

<TRUE::operators>

<FALSE::operators>

<[1] = [1]>

や

<<> かつ <>>

で代用も容易なので、不要だと思います。
間違った使い方かもしれませんが、これ以上パレットをごちゃごちゃさせるよりは良いように思います。

⑦

([ v]をunicodeで[デコード v]::operators)

使用用途や使う人が非常に限られていると思います。
その上、クラウドチャットへの悪用への心配があります。反対です。

⑧

([]を計算::operators)

これも使用用途は非常に限られていると思いますし、
式の表記方法にも表記揺れが発生することは想像がつきます。反対です。

⑨ ⑩

<[] ≦ []::operators>
<[] ≧ []::operators>
<[] ≠ []::operators>

それぞれ、

<<[] ＞ []> ではない>
<<[] = []> ではない>

で簡単に代用できます。
見た目やプログラムのスッキリさも大して変わるような気はしません。

Last edited by newmomizi_txt (March 23, 2022 08:32:25)

mitaku115

今まで提案されてきた演算ブロックはほぼ使い道がないと思いますし、
これ以上ブロックを増やしたらごちゃごちゃするので普通に追加するのは反対ですが、
拡張機能的で追加するのは全て異論はありません。
と、いってもそろそろこれらのブロックを「異論のない提案」に入れるか議論するのではなく、
STに今まで提案されてきて、問題のない内容を提案する作業に入るべきだと思います。

Doctor_Fe

#550
⑥について、もちろん、メインループ内の分岐に置く意味はあまりないでしょう。
しかし、定義を使うときは別です。呼び出し側から定義内の分岐先を指定したいことが多々あります。
そして、「定義の呼び出し時の状態(変数の値、スプライトの状態など)」ではなく、「定義の呼び出し元(どこから呼び出したか)」が分岐先の変更の理由になることもあります。
定義の引数について、ある場所からは必ずtrueで、別の場所からは必ずfalseに指定する事があるということです。
そういう時には、真偽値ブロックは非常に役に立ちます。

それに加えて、私は真偽値は数字や文字列と同じくらいプログラミングで基本的な要素と考えています。プログラミングを語れるほど長いことやっているわけではありませんが。
それなので、真偽値ブロックはないほうがおかしいというのが僕の立場です。
代用法というのも、本来何かを入れるところに何もいれないなど、あまり好ましい使い方ではないし、わかりにくいと思います。
テキストベース言語で“1 == 1”や“!(0)”, “0 || 0”のように書いていると言えば、不自然に感じる理由がわかると期待します。

(これは#551についてもです。)
無駄に思えるブロックかもしれませんが、意味が理解できない人にとっては、既にあるsin, cos, log等も無駄なブロックなのではないですか?

newmomizi_txt

Doctor_Fe wrote:
#550
⑥について、もちろん、メインループ内の分岐に置く意味はあまりないでしょう。
しかし、定義を使うときは別です。呼び出し側から定義内の分岐先を指定したいことが多々あります。
そして、「定義の呼び出し時の状態(変数の値、スプライトの状態など)」ではなく、「定義の呼び出し元(どこから呼び出したか)」が分岐先の変更の理由になることもあります。
定義の引数について、ある場所からは必ずtrueで、別の場所からは必ずfalseに指定する事があるということです。
そういう時には、真偽値ブロックは非常に役に立ちます。

確かに、定義ブロックの引数で使いそうですね。修正しておきます

inoking

#549 がこれまでの議論内容をよく反映していると思います。
この場合、①は異論なしでしょうか。

日本時間 3/24 18:00 までに特に異論なければ合意が取れたものとします。

Last edited by inoking (March 23, 2022 09:31:11)

inoking

mitaku115 wrote:
STに今まで提案されてきて、問題のない内容を提案する作業に入るべきだと思います。

これはどういうことでしょうか？

p_nuts

scratch_camp2021 wrote:
メッセージに関する提案二つ。
まず、スタジオの活動通知はフォローしたスタジオのみが通知されるようにしてほしいです。
次に、メッセージのジャンル見たいので、フォローというジャンルを追加してほしいです。
クラウド変数が誰でも使えるようになったらうれしいけどそんなのあり得ないよね

そもそも、スタジオの役職につくというのはどういうことなのか考えてみてください。
クラウド変数が使えないのはスパム防止のためですよ？(自分の出した結論ですが、なぜわざわざ使えないのか考えてみてください)

scratch_camp2021

#556 あ、、理解しました。

-_plus_-

僕はメッセージでも引数のように文字列や値を送れるようにしてもらいたいです。
使うとき
スコアやタイムを送る
欲しい理由
いちいち変数に文字列などを移して送るのが面倒だから。

[ v] を受け取ったとき(文字列)(値) :: hat

[ v] を送る[][]

Last edited by -_plus_- (March 25, 2022 00:14:54)

yukku

>> #558
メッセージよりも定義ブロックとして実装して「非同期関数」という位置づけにするべきだと思います。

inoking

yukku wrote:
メッセージよりも定義ブロックとして実装して「非同期関数」という位置づけにするべきだと思います。

実装するのは ST ですか？
もしそうなら「定義をスプライトを跨いでの使用可能」なら既に「異論のない提案」にありますが
それとは異なりますか？

Last edited by inoking (March 25, 2022 03:04:54)

yukku

>> #560

foo[引数]
X::grey
定義 foo(arg)
Y::grey

でXとYが同時に実行されるイメージです。

yukku

間違えて投稿しました。すみません。

Last edited by yukku (March 25, 2022 08:38:16)

inoking

#561:
同時にであればメッセージを使うほうが自然でしょう。
しかし、「同時に実行」といってもある瞬間で実行している処理は一つだけなので
実行タイミングが分かりにくくかえってややこしいことになります。
よって、Scratch には不向きと思います。

実際、「旗を二度押してください」みたいなのも実行タイミングが制御できていないからです。

inoking

演算カテゴリーの反映は終わっていませんが、変数カテゴリーの仕分けを提示しておきます。

・クラウドリスト → 明らかに却下なので外します。

1.
・リストの名前変更 ← #575 により除外

2.
・他のプロジェクトとの変数共有

3.
・ユーザーごとに保存される変数

4.
・保存するとリストの大きさが変わる仕様修正
（これ何でしたっけ？Scratch 2.0 時代のバグで今は解消されているような？）

5.
・(9.) プログラム内での変数宣言

変数 [変数 v] を作る ::variables

↑ #581 により一つにまとめる

6.

変数 [変数 v] を [#f5f] にする ::variables

7.

(1 v) 番目 [リスト v] を (1) ずつ変える ::list

8.
・https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2839913/

<変数::variables>//真偽値型

今回これを強調しておきます。

みなさんへ：
各自が仕分けの全項目についてコメントしていくと煩雑になります。
多数決を取っているわけではないので
意見は差分だけ述べるようにお願いします。
このような場では基本的に、反論なしは同意とみなしてよいでしょう。

仕分けがすむまで、新規の提案はなるべくしないようにお願いします。
また、仕分けについての意見の際は過去の議論をふまえてコメントをお願いします。

Last edited by inoking (March 26, 2022 07:28:59)

_-ehu-_

#564
1.賛成。したい時が多くあるし、追加しても混乱は発生しない。
2.賛成。よりプロジェクトが拡張できる。実際に、空想世界の天気を共有したいと思ったことがある。ただし、するなら自分のプロジェクト内のみ？(変数名が被ってしまうとどうなるのか？それとも確認コード的なものを入力するのか？)
3.クラウド変数で代用できるが、Cookieを使用して保存するなら賛成。ログイン無しでも保存できると良いと思う。
4.まだバグがあるなら賛成。
5.反対。使いたい時がない、リストで代用可能。
6.？背景のオレンジ色の部分を変えるということなら賛成。実際、背景に合わせた変数が使いたいことがある。
7.あれば使う。なくてもよい。
8.賛成。結構使いたい時がある。
9.反対。初心者が混乱する。

StrongPeanut

1 と 4 と 6 は _-ehu-_ さんと一緒です。

2. クラウド変数のデータだけなら賛成。ただの変数なら使いにくい。
3. そんなことをするならクラウドリストを頑張って作って管理すべき。
5. スクリプト内でどうしても作るしかない理由がない。
7.

(1) 番目 [list v] を (((1) 番目 [list v]:: list) + (1)) で置き換える::list

これくらいの代用があるため反対。
8. 変数で TRUE を返す？意味がわからない＆初心者が混乱する恐れありと言うことで反対。
9. 意味がわかりません。

Kankitsu_0910

１賛成。あってもデメリットはなく、名前を間違えてリストを作った時の中身の移動の手間もない。
２賛成。世界記録の共有、リアルタイムでの他プロジェクトからの情報の転送などいろいろ使い道がある。技術的にも可能。ただし却下された仮想通貨ブロックになりかねないので共有同期できるプロジェクト数に制限をかけるなどの対策が必要そう。
３賛成。scratchサーバーやCookieなどどこに保存されるかが問題だが、クラウド変数式よりも多くのデータや文字(クラウド変数式では最大2560文字しか入らない(データを保存できるユーザ数に制限がかかる)上数字しか使えない)を格納できるので便利だと思う。
４遭遇したことがないのでよくわかりません。
５そもそも

[変数 v]::stack variables

に引数が入られられないので使えない。
６反対。特に使う場面はない。ステージの指定した座標の色を検出する機能の実装のほうが望ましい。
７反対。簡単に代用可能。初心者用の実装はありかもしれない。
８欲しいが少々問題がある。

<>::stack grey
に
(引数::grey)
が入ってしまうなど

作成時に型を指定する仕様ならなんとかなりそう
９反対、 _-ehu-_さんと同じ

追記
※ここのみ２の変数のことを同期変数と呼ばせていただきます
２は1プロジェクト毎に使える同期変数を1種類（「世界記録」「闇の黙示録」「東方見聞録」の3つの同期変数があった場合、一つのプロジェクトにつきいずれか一つの同期変数しか使えない）にするべき。変数から変数への受け渡しでどんどん拡張できてしまう。

追追記
８は

<(変数) = [true]>

で代用可能なので実装しなくても良い気がする

追追追記
1はもう実装されているとのことなので除外

Last edited by Kankitsu_0910 (March 26, 2022 07:35:33)

Discuss Scratch