Scratch 3.0 への提案

takasyu

スプライトごとに全く同じ定義を作るのではダメでしょうか？

ITM126

#7990　それをすることによってどんなメリットが生じますか？

k_mario

メッセージを送って、受け取った時に定義を実行すればどこからでもその定義を実行できると思います。

k_mario

確かに、、、　でも変数に値を入れておけば一応できますね。

k_mario

全スプライト用の定義を編集する場所を新たに設ければいいと思います。

ITM126

もう一度聞きますが、「変数と同じように定義も全スプライト用とこのスプライトのみで、選択できるようにする」ことによって生じるメリットはなんですか？
#7993　「いろんなスプライトで使える定義を作成したときに、他のスプライトにコピーするのが大変」なのはわかりますが、それは定義の名前（わからなかったらすみません）を移動できるだけで、定義自体を移動することにはならないのでしょうか。

ITM126

それなら、音を全スプライトで共有できるようにしたいです。

inoking

グローバル関数は有用だと思います。
※既にこれまでもその提案はあったのですが見つけられませんでした。

少なくともコードをコピーするのは悪習です。

Scratch はオブジェクト指向でもあるのでグローバル関数を用意していないのかもしれません。
メッセージに引数をもたせるのでもいいですけどね。

abee

Scratchのグローバル変数は、ステージというオブジェクトのローカル変数という扱いなので、それと同じようにステージのブロック定義がグローバルになるというのが一つの方法ですね。
Scratchのオブジェクト(スプライト、ステージ)は、引数を含め、変数に代入できない(第一級オブジェクトではない)ことで、いろいろな制約が生じていますが、ここを変えると大変更になるので、それはちょっと難しいような気がします。

inoking

abee wrote:
Scratchのグローバル変数は、ステージというオブジェクトのローカル変数という扱いなので、それと同じようにステージのブロック定義がグローバルになるというのが一つの方法ですね。

それが違和感なさそうです。
Excel などの VBA でも「標準モジュール」というカテゴリーがありますが、それと似たようなものでしょうか。

abee

ただ、その場合、ブロック定義内で使える変数がグローバル変数になるので、情報隠蔽の意味では厳しいことになります。
あと、他のブロック定義もそうですが、ブロック定義内に閉じたスコープの変数が作れず、再入不能なので、マルチスレッドのScratchでは使いにくいこともあります。

inoking

再入不能（リエントラントでなくなる）は「動きません～」といったトラブルが多発しそうですね。
abee さんのおっしゃるとおり現在の定義でも（クローンを使った場合など）同様の問題がありますが
グローバル関数として並列で使われやすくなるとその傾向が増しそうです。

k_mario

スタジオで、マネージャーの人をキュレーターに戻す(降格)が欲しい。
マネージャーは40人までなので、減らす際に消すのではなくキュレーターとして残しておける。

Last edited by k_mario (Dec. 26, 2021 10:30:23)

ITM126

#8007　確かに、欲しい機能ではありますが、何か問題がありそうな気もします。（なんかはわからないけど）

Ke0

降格するくらいだったら最初から昇格しない方がいいでしょう。
「そういうことじゃない！」と思うかもしませんが、後に降格するような人をマネージャーにしないようまず心がけることです。

ITM126

#8009コメント（#8007)をよく読んでくれますか

Last edited by ITM126 (Dec. 26, 2021 11:49:07)

fugu_fugu

#8011
結局それも#8009を守ればいいだけだと思います。「足りない！」となるのであればマネージャーの重みを考えるべきではないでしょうか？

ITM126

#8012 そもそも論ですが、#8009の意見にはおかしいところがあります。「後に降格するような人をマネージャーにしないようまず心がけることです。」とありますが、本当に信用できて、この人をマネージャーにしたいという気持ちが同じくらいある人が40人、もしくはそれ以上いた場合、後に降格するような人をマネージャーにしないようまず心がけたとしても、マネージャーはすぐに40人に達してしまいました。それでも、この人には自分のスタジオにいてほしい！と思っているなら、その人を降格しキュレーターとしてそのスタジオに残すことができます。再招待するという手もあるのですが、その人がブロック中だったり活動休止中だったりしたらすぐには来れませんし、引退してしまった人が残っている場合も、消したくないけど消さなければいけない場合に陥ることになります。その場合に降格機能というのはとても役立つと思います。

Last edited by ITM126 (Dec. 26, 2021 11:46:22)

Es-2

#8013
ブロック中だったり活動休止中だったり引退している人をスタジオに残しておく必要はないと思います。

inoking

さらにそもそも論ですが
美術館の例え（Scratch のスタジオが元はギャラリーであったことから美術館によく例えられます）で言うと

一つの美術館で学芸員（居ても数十人？）の人事権を持つ管理者（マネージャー）が40人も必要なはずがありません。
どれだけ大きな美術館なのでしょう？

一般的組織では、一人が直接管理可能な人数は多くて数十人です。
私はマネージャーはもっと少なくてよいと考えています。
※過去との互換性からいきなり減らすのも問題があるので
　Scratch チームは 40人という数字を選択したのではないでしょうか。

Discuss Scratch