Discuss 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 への提案

何をもって同じと言っているのかが分かりません。

kyokyoro wrote:

[変数 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
9 posts

Scratch への提案

もし欠けている部分があったり意味が分からない文章だったらすいません。
「右クリックされた」ブロックがあったらいいなと思います。
理由としては、操作性の幅を広げたいためです。
見た目は、マウスが押されたブロックに v を追加する、
OOキーが押されたに追加する、または新しく追加する
<key [右クリック v] pressed?>

<mouse down?>
ここのマウスが右クリックになるイメージ

また、新しく追加するなら、マウスが押されたブロックの名前も変わるかも(しれません)。
(左クリックまたはクリック?) あとがき:ブロックが英語になってました…

Last edited by arugakuseidesu (April 9, 2026 11:13:40)

inoking
Scratcher
1000+ posts

Scratch への提案

abee wrote:

変数とリストの値の相互変換が可能であれば、あるリストの要素を他のリストにコピーすることも簡単にできるので、実質的に#9084の提案の内容を実現できます。
はい、そうです。
ただ、複合ブロックの話はしていないことは #9105 に書いたとおりです。
inoking
Scratcher
1000+ posts

Scratch への提案

arugakuseidesu wrote:

「右クリックされた」ブロックがあったらいいなと思います。
理由としては、操作性の幅を広げたいためです。
見た目は、マウスが押されたブロックに v を追加する、
OOキーが押されたに追加する、または新しく追加する
<key [右クリック v] pressed?>

<mouse down?>
ここのマウスが右クリックになるイメージ
タブレットなどでは右クリックに対応できません。
kyokyoro
Scratcher
100+ posts

Scratch への提案

そもそも、変数をリストに変換するというのがよくわからないので、文字列をリストに変換するという意味であれば、リスト->文字列->リストのように受け渡しできるのではないですか
さらに、変換したオブジェクトを操作するには必然的に代入が必要なので、変換の提案 ≒ 代入の提案だと感じます

inoking wrote:

これは目的も動作も「リスト同士の代入」とは違います。
動作が異なるというのが本当に理解できず、なんのためのブロック、機能なのか理解するのが難しそうなので、ここら辺で話は終えておきます
ありがとうございました

[追記]
最後に添えておきますが、リストは変数に代入することによって初めて文字列になるわけではなく、そのブロック自体が変換済み文字列を返すため、
リスト [リスト1 v] を (リスト2 ::list) にする ::list
というのはリスト2->リスト1ではなくリスト2->文字列->リスト1という意味だったということだけ書いておきます

Last edited by kyokyoro (April 9, 2026 12:39:43)

inoking
Scratcher
1000+ posts

Scratch への提案

kyokyoro wrote:

そもそも、変数をリストに変換するというのがよくわからないので、文字列をリストに変換するという意味であれば、リスト->文字列->リストのように受け渡しできるのではないですか
さらに、変換したオブジェクトを操作するには必然的に代入が必要なので、変換の提案 ≒ 代入の提案だと感じます

inoking wrote:

これは目的も動作も「リスト同士の代入」とは違います。
動作が異なるというのが本当に理解できず、なんのためのブロック、機能なのか理解するのが難しそうなので、ここら辺で話は終えておきます
ありがとうございました
文字列をリストに変換するという意味です。

他言語でいうところの split のようなイメージです。
リストに分割した後でそれをどう使うかは使い方しだいです。
操作するには代入が必要ということはありません。


直接的には
リストから文字列に自動で変換されるなら、その逆もあっていいのでは。
ということですが、

これが活きてくるのは定義を使うときです。
定義の引数や(いつか実装されるかもしれない)戻り値にはリストは指定できませんが、
変数(文字列)に結合して容易にやり取りできるようになるということです。
現状は、結合はできますがその逆がありません。


[追記]
最後に添えておきますが、リストは変数に代入することによって初めて文字列になるわけではなく、そのブロック自体が変換済み文字列を返すため、
リスト [リスト1 v] を (リスト2 ::list) にする ::list
というのはリスト2->リスト1ではなくリスト2->文字列->リスト1という意味だったということだけ書いておきます
内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います。
kyokyoro
Scratcher
100+ posts

Scratch への提案

#9113

inoking wrote:

他言語でいうところの split のようなイメージです。
リストに分割した後でそれをどう使うかは使い方しだいです。
操作するには代入が必要ということはありません。
仮にこの機能(変換機能)が追加されるとして、Scratchの言語思想において、変換されたリストオブジェクトをリストに代入せずに操作する方法(例えば下記)が同時に実装されるとしても、代入機能の追加は不可欠だと思います。inokingさんの提案がリストの代入機能を含まないなら、その追加を提案します。
(というかそもそもあくまで変換機能だけの提案ならあの書き方はややこしすぎると思います。)
( (return_list) の (2) 番目 ::list)

inoking wrote:

内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います。
(リスト)はリストオブジェクトを返さず、文字列を返します。よって、変数を経由する必要はなく、既に以下のような使い方もできます。

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 への提案

順番前後しますが

kyokyoro wrote:

inoking wrote:

内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います。
(リスト)はリストオブジェクトを返さず、文字列を返します。よって、変数を経由する必要はなく、既に以下のような使い方もできます。
~略~
say (words ::list) //Result: I am a student.
そのことを「内部的に変換されるとしてもそれを取り出すには変数に入れるしかないと思います」と言っています。
inoking
Scratcher
1000+ posts

Scratch への提案

kyokyoro wrote:

仮にこの機能(変換機能)が追加されるとして、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 wrote:

リスト [コピー先 v] を (return_list) にする ::list//return_list はスカラー変数
これらは代入の提案とは何が違うんですか?

——
話を戻して、結局のところ最初に聞きたかったのは
リスト [コピー先 v] を (コピー元 ::list) にする ::list
が期待通りに動くか否かです。inokingさんによると「目的も動作も違う」と言うことでしたが、inokingさんのお話を聞く限り正常に動いてくれないとおかしいです。(リスト)はリストオブジェクトではなく文字列であり、それはinokingさんも認識されていることと、inokingさんの「文字列をリストに変換するという意味」という発言を踏まえると、どうも期待通りに動く気がしてなりません。
inoking
Scratcher
1000+ posts

Scratch への提案

kyokyoro wrote:

inokingさんは定義の返り値としてリストを使えるようにするため、というのが提案の理由とはなっていますが、他にもいろいろな使い道があります。
以下のように書いていますが、一例にすぎません。

inoking wrote:

これが活きてくるのは定義を使うときです。
「他にも使えるじゃないか」というのは
9年前の提案だったため考慮が不足していたということでご容赦ください。
inoking
Scratcher
1000+ posts

Scratch への提案

どちらがおかしいというのではなく、依然として話していることがズレているように思います。
何が事実で、何が前提で、どういう仮定を置いたとき、何を推測しているのかが分かりません。

異論のない提案にあるものは以下で
リスト [コピー先 v] を (変数) にする ::list
kyokyoro さんが同じと言っているものは以下です。
リスト [コピー先 v] を (コピー元 ::list) にする ::list
これは事実です。


何がズレているのかが分かった気がします。

一般に、ブロックの丸型のプレースホルダには
文字列、変数、リストが入れられるので
リスト [コピー先 v] を [any text] にする ::list // ここに文字数を入れられる
リスト [コピー先 v] を (変数) にする ::list // ここに変数を入れられる
リスト [コピー先 v] を (コピー元 ::list) にする ::list // ここにリストも入れられる
kyokyoro さんは 「右辺にリストを入れたらどうなるか」の話をしていたのですね?

であれば、答えは「イエス」です。
副作用として実現されるということです。
Zirconium_Tungstate
New Scratcher
4 posts

Scratch への提案

いくつか提案をさせてもらいます

提案1:持とうとしているブロックのハイライト機能
理由:丸形や六角形ブロックがたくさん重なっている部分は、どこを掴むのかが分かりづらく間違えてつかむことが多々ある

提案2:変数、リスト作成画面に“このスプライト用”がクローンごとに保存されることを示す情報の追加
理由:初心者のころにクローンごとに保存される変数が欲しいと思ったことがあり、“このスプライト用”にしたらクローンごとに保存されることが知らないまましばらく諦めていた

提案3:ブロック定義作成画面に“画面を再描画せずに実行”がほぼ遅延なしで実行されることを示す情報の追加
理由:提案2の理由と似ていて、“画面を再描画しない”というのがどういうことなのかよく分からなかった、“ほぼ遅延がない”という事実をより早く知りたかった
tsukebo_sumajan
Scratcher
51 posts

Scratch への提案

おはようございます。提案させて頂きます。

拡張機能の音源合成機能の音声の種類を増やす です。
理由:
・音声の種類が少ない
・音声を増やすと、色んなこと(例えばゲーム、アニメ)等に活用できる
kururinnhoppu
Scratcher
41 posts

Scratch への提案

#9118
私は3つとも賛成です

1つ目、持ったブロックのハイライト

理由は私も間違って掴んでしまうことが多いからです

それに、例えば
(join [りんご] [バナナ])

(foo)
を入れるときなどは、どこに入るのか光って分かるようになっているので
掴むブロック、掴んでいるブロックのハイライトはできると思います

2つ目と3つ目について

私は知りませんでした…
知っていたら作れたものがあったので悔しい…
なのでほしいです。文章を追加するだけで大規模に変える必要がないので通りやすいかなーと個人的に思いました

語彙力なくてごめんね
gccxnondx
Scratcher
100+ posts

Scratch への提案

#9118
ズームの機能を使えばよい。私的には今でも十分つかめると思っているんですが

Wikiに載っている。知っている人から教えてもらえばよい。

これもWikiに載っている。

以上の理由で全て反対します。

Powered by DjangoBB