Discuss Scratch
- Discussion Forums
- » 日本語
- » Scratch への提案
- kyokyoro
-
Scratcher
100+ posts
Scratch への提案
ええ、つまり期待通り動くのではないですか?
コピー元が
コピー先は
コピー元が
- aa
- bb
- cc
(コピー元 ::list) // "aa bb cc"なので
リスト [コピー先 v] を (コピー元 ::list) にする ::listを実行した時
コピー先は
- aa
- bb
- cc
[変数 v] を (コピー元 ::list) にすると動作的には同じだと思います
リスト [コピー先 v] を (変数) にする ::list
Last edited by kyokyoro (April 8, 2026 17:21:35)
- inoking
-
Scratcher
1000+ posts
Scratch への提案
何をもって同じと言っているのかが分かりません。
異論のない提案にあるものは、あくまで
の話はしていません。[変数 v] を (コピー元 ::list) にすると動作的には同じだと思います
リスト [コピー先 v] を (変数) にする ::list
異論のない提案にあるものは、あくまで
リスト [コピー先 v] を (変数) にする ::listだけの話です。
- kyokyoro
-
Scratcher
100+ posts
Scratch への提案
リスト [リスト v] を [any text] にする ::listではなく
リスト [リスト v] を (変数) にする ::list // ここに変数を入れられる
リスト [リスト v] を [変数 v] にする ::listというブロックを期待しているということですか?それなら納得です
夜分遅くまで付き合わせてしまって申し訳ありませんでした
- inoking
-
Scratcher
1000+ posts
Scratch への提案
何か全然違う話をしているように思えます。
右辺に変数がハマるとかハマらないとか、選択肢から選ぶとかではなく、
そもそも、現状、リストに対する操作は「削除」、「追加」、「置換」だけで、「代入」のブロックはありません。
異論のない提案にあるものは
「代入」を追加しようという話ではなく
変数との「変換」を追加しようという話です。
右辺に変数がハマるとかハマらないとか、選択肢から選ぶとかではなく、
そもそも、現状、リストに対する操作は「削除」、「追加」、「置換」だけで、「代入」のブロックはありません。
異論のない提案にあるものは
「代入」を追加しようという話ではなく
変数との「変換」を追加しようという話です。
- abee
-
Scratcher
1000+ posts
Scratch への提案
変数とリストの値の相互変換が可能であれば、あるリストの要素を他のリストにコピーすることも簡単にできるので、実質的に#9084の提案の内容を実現できます。
Last edited by abee (April 9, 2026 00:20:13)
- arugakuseidesu
-
Scratcher
12 posts
Scratch への提案
もし欠けている部分があったり意味が分からない文章だったらすいません。
「右クリックされた」ブロックがあったらいいなと思います。
理由としては、操作性の幅を広げたいためです。
見た目は、マウスが押されたブロックに v を追加する、
OOキーが押されたに追加する、または新しく追加する
また、新しく追加するなら、マウスが押されたブロックの名前も変わるかも(しれません)。
(左クリックまたはクリック?) あとがき:ブロックが英語になってました…
「右クリックされた」ブロックがあったらいいなと思います。
理由としては、操作性の幅を広げたいためです。
見た目は、マウスが押されたブロックに v を追加する、
OOキーが押されたに追加する、または新しく追加する
<key [右クリック v] pressed?>
<mouse down?>ここのマウスが右クリックになるイメージ
また、新しく追加するなら、マウスが押されたブロックの名前も変わるかも(しれません)。
(左クリックまたはクリック?) あとがき:ブロックが英語になってました…
Last edited by arugakuseidesu (April 9, 2026 11:13:40)
- inoking
-
Scratcher
1000+ posts
Scratch への提案
「右クリックされた」ブロックがあったらいいなと思います。タブレットなどでは右クリックに対応できません。
理由としては、操作性の幅を広げたいためです。
見た目は、マウスが押されたブロックに v を追加する、
OOキーが押されたに追加する、または新しく追加する<key [右クリック v] pressed?><mouse down?>ここのマウスが右クリックになるイメージ
- kyokyoro
-
Scratcher
100+ posts
Scratch への提案
そもそも、変数をリストに変換するというのがよくわからないので、文字列をリストに変換するという意味であれば、リスト->文字列->リストのように受け渡しできるのではないですか
さらに、変換したオブジェクトを操作するには必然的に代入が必要なので、変換の提案 ≒ 代入の提案だと感じます
ありがとうございました
[追記]
最後に添えておきますが、リストは変数に代入することによって初めて文字列になるわけではなく、そのブロック自体が変換済み文字列を返すため、
さらに、変換したオブジェクトを操作するには必然的に代入が必要なので、変換の提案 ≒ 代入の提案だと感じます
これは目的も動作も「リスト同士の代入」とは違います。動作が異なるというのが本当に理解できず、なんのためのブロック、機能なのか理解するのが難しそうなので、ここら辺で話は終えておきます
ありがとうございました
[追記]
最後に添えておきますが、リストは変数に代入することによって初めて文字列になるわけではなく、そのブロック自体が変換済み文字列を返すため、
リスト [リスト1 v] を (リスト2 ::list) にする ::listというのはリスト2->リスト1ではなくリスト2->文字列->リスト1という意味だったということだけ書いておきます
Last edited by kyokyoro (April 9, 2026 12:39:43)
- inoking
-
Scratcher
1000+ posts
Scratch への提案
そもそも、変数をリストに変換するというのがよくわからないので、文字列をリストに変換するという意味であれば、リスト->文字列->リストのように受け渡しできるのではないですか文字列をリストに変換するという意味です。
さらに、変換したオブジェクトを操作するには必然的に代入が必要なので、変換の提案 ≒ 代入の提案だと感じますこれは目的も動作も「リスト同士の代入」とは違います。動作が異なるというのが本当に理解できず、なんのためのブロック、機能なのか理解するのが難しそうなので、ここら辺で話は終えておきます
ありがとうございました
他言語でいうところの split のようなイメージです。
リストに分割した後でそれをどう使うかは使い方しだいです。
操作するには代入が必要ということはありません。
直接的には
リストから文字列に自動で変換されるなら、その逆もあっていいのでは。
ということですが、
これが活きてくるのは定義を使うときです。
定義の引数や(いつか実装されるかもしれない)戻り値にはリストは指定できませんが、
変数(文字列)に結合して容易にやり取りできるようになるということです。
現状は、結合はできますがその逆がありません。
[追記]内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います。
最後に添えておきますが、リストは変数に代入することによって初めて文字列になるわけではなく、そのブロック自体が変換済み文字列を返すため、リスト [リスト1 v] を (リスト2 ::list) にする ::listというのはリスト2->リスト1ではなくリスト2->文字列->リスト1という意味だったということだけ書いておきます
- kyokyoro
-
Scratcher
100+ posts
Scratch への提案
#9113
(というかそもそもあくまで変換機能だけの提案ならあの書き方はややこしすぎると思います。)
words
他言語でいうところの split のようなイメージです。仮にこの機能(変換機能)が追加されるとして、Scratchの言語思想において、変換されたリストオブジェクトをリストに代入せずに操作する方法(例えば下記)が同時に実装されるとしても、代入機能の追加は不可欠だと思います。inokingさんの提案がリストの代入機能を含まないなら、その追加を提案します。
リストに分割した後でそれをどう使うかは使い方しだいです。
操作するには代入が必要ということはありません。
(というかそもそもあくまで変換機能だけの提案ならあの書き方はややこしすぎると思います。)
( (return_list) の (2) 番目 ::list)
内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います。(リスト)はリストオブジェクトを返さず、文字列を返します。よって、変数を経由する必要はなく、既に以下のような使い方もできます。
words
- I
- am
- a
- student.
(words ::list) と言う //Result: I am a student.
Last edited by kyokyoro (April 9, 2026 13:28:33)
- inoking
-
Scratcher
1000+ posts
Scratch への提案
順番前後しますが
そのことを「内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います」と言っています。内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います。(リスト)はリストオブジェクトを返さず、文字列を返します。よって、変数を経由する必要はなく、既に以下のような使い方もできます。
~略~say (words ::list) //Result: I am a student.
- inoking
-
Scratcher
1000+ posts
Scratch への提案
仮にこの機能(変換機能)が追加されるとして、Scratchの言語思想において、変換されたリストオブジェクトをリストに代入せずに操作する方法(例えば下記)が同時に実装されるとしても、代入機能の追加は不可欠だと思います。inokingさんの提案がリストの代入機能を含まないなら、その追加を提案します。すみません、ちょっと意味が分かりません。
(というかそもそもあくまで変換機能だけの提案ならあの書き方はややこしすぎると思います。)( (return_list) の (2) 番目 ::list)
以下で済むように思います。
リスト [コピー先 v] を (return_list) にする ::list//return_list はスカラー変数
( [コピー先 v] の (2) 番目 ::list)
追記:
最初の提案のときから書いているように
「おそらくリスト型の引数や戻り値はサポートされないでしょう」という前提があります。
Last edited by inoking (April 9, 2026 13:35:51)
- kyokyoro
-
Scratcher
100+ posts
Scratch への提案
?それはまあ定義の返り値として使う場合は変数に入れるしかないですが、普通に使う分には別に変数に入れる必要はないのでは?
inokingさんは定義の返り値としてリストを使えるようにするため、というのが提案の理由とはなっていますが、他にもいろいろな使い道があります。
——
話を戻して、結局のところ最初に聞きたかったのは
inokingさんは定義の返り値としてリストを使えるようにするため、というのが提案の理由とはなっていますが、他にもいろいろな使い道があります。
これらは代入の提案とは何が違うんですか?リスト [コピー先 v] を (return_list) にする ::list//return_list はスカラー変数
——
話を戻して、結局のところ最初に聞きたかったのは
リスト [コピー先 v] を (コピー元 ::list) にする ::listが期待通りに動くか否かです。inokingさんによると「目的も動作も違う」と言うことでしたが、inokingさんのお話を聞く限り正常に動いてくれないとおかしいです。(リスト)はリストオブジェクトではなく文字列であり、それはinokingさんも認識されていることと、inokingさんの「文字列をリストに変換するという意味」という発言を踏まえると、どうも期待通りに動く気がしてなりません。
- inoking
-
Scratcher
1000+ posts
Scratch への提案
inokingさんは定義の返り値としてリストを使えるようにするため、というのが提案の理由とはなっていますが、他にもいろいろな使い道があります。以下のように書いていますが、一例にすぎません。
これが活きてくるのは定義を使うときです。「他にも使えるじゃないか」というのは
9年前の提案だったため考慮が不足していたということでご容赦ください。
- inoking
-
Scratcher
1000+ posts
Scratch への提案
どちらがおかしいというのではなく、依然として話していることがズレているように思います。
何が事実で、何が前提で、どういう仮定を置いたとき、何を推測しているのかが分かりません。
異論のない提案にあるものは以下で
何がズレているのかが分かった気がします。
一般に、ブロックの丸型のプレースホルダには
文字列、変数、リストが入れられるので
であれば、答えは「イエス」です。
副作用として実現されるということです。
何が事実で、何が前提で、どういう仮定を置いたとき、何を推測しているのかが分かりません。
異論のない提案にあるものは以下で
リスト [コピー先 v] を (変数) にする ::listkyokyoro さんが同じと言っているものは以下です。
リスト [コピー先 v] を (コピー元 ::list) にする ::listこれは事実です。
何がズレているのかが分かった気がします。
一般に、ブロックの丸型のプレースホルダには
文字列、変数、リストが入れられるので
リスト [コピー先 v] を [any text] にする ::list // ここに文字数を入れられるkyokyoro さんは 「右辺にリストを入れたらどうなるか」の話をしていたのですね?
リスト [コピー先 v] を (変数) にする ::list // ここに変数を入れられる
リスト [コピー先 v] を (コピー元 ::list) にする ::list // ここにリストも入れられる
であれば、答えは「イエス」です。
副作用として実現されるということです。
- Zirconium_Tungstate
-
New Scratcher
4 posts
Scratch への提案
いくつか提案をさせてもらいます
提案1:持とうとしているブロックのハイライト機能
理由:丸形や六角形ブロックがたくさん重なっている部分は、どこを掴むのかが分かりづらく間違えてつかむことが多々ある
提案2:変数、リスト作成画面に“このスプライト用”がクローンごとに保存されることを示す情報の追加
理由:初心者のころにクローンごとに保存される変数が欲しいと思ったことがあり、“このスプライト用”にしたらクローンごとに保存されることが知らないまましばらく諦めていた
提案3:ブロック定義作成画面に“画面を再描画せずに実行”がほぼ遅延なしで実行されることを示す情報の追加
理由:提案2の理由と似ていて、“画面を再描画しない”というのがどういうことなのかよく分からなかった、“ほぼ遅延がない”という事実をより早く知りたかった
提案1:持とうとしているブロックのハイライト機能
理由:丸形や六角形ブロックがたくさん重なっている部分は、どこを掴むのかが分かりづらく間違えてつかむことが多々ある
提案2:変数、リスト作成画面に“このスプライト用”がクローンごとに保存されることを示す情報の追加
理由:初心者のころにクローンごとに保存される変数が欲しいと思ったことがあり、“このスプライト用”にしたらクローンごとに保存されることが知らないまましばらく諦めていた
提案3:ブロック定義作成画面に“画面を再描画せずに実行”がほぼ遅延なしで実行されることを示す情報の追加
理由:提案2の理由と似ていて、“画面を再描画しない”というのがどういうことなのかよく分からなかった、“ほぼ遅延がない”という事実をより早く知りたかった
- tsukebo_sumajan
-
Scratcher
54 posts
Scratch への提案
おはようございます。提案させて頂きます。
拡張機能の音源合成機能の音声の種類を増やす です。
理由:
・音声の種類が少ない
・音声を増やすと、色んなこと(例えばゲーム、アニメ)等に活用できる
拡張機能の音源合成機能の音声の種類を増やす です。
理由:
・音声の種類が少ない
・音声を増やすと、色んなこと(例えばゲーム、アニメ)等に活用できる
- kururinnhoppu
-
Scratcher
41 posts
Scratch への提案
#9118
私は3つとも賛成です
1つ目、持ったブロックのハイライト
理由は私も間違って掴んでしまうことが多いからです
それに、例えば
掴むブロック、掴んでいるブロックのハイライトはできると思います
2つ目と3つ目について
私は知りませんでした…
知っていたら作れたものがあったので悔しい…
なのでほしいです。文章を追加するだけで大規模に変える必要がないので通りやすいかなーと個人的に思いました
語彙力なくてごめんね
私は3つとも賛成です
1つ目、持ったブロックのハイライト
理由は私も間違って掴んでしまうことが多いからです
それに、例えば
(join [りんご] [バナナ])に
(foo)を入れるときなどは、どこに入るのか光って分かるようになっているので
掴むブロック、掴んでいるブロックのハイライトはできると思います
2つ目と3つ目について
私は知りませんでした…
知っていたら作れたものがあったので悔しい…
なのでほしいです。文章を追加するだけで大規模に変える必要がないので通りやすいかなーと個人的に思いました
語彙力なくてごめんね