The join operator block should be able to be put in the variable selector of a data block so I can specify what variable I want to modify. This can be helpful when using a self-made Block.

For example, If I have a long stack of blocks meant to add text to two lists, instead of using the regular add item to list block and manually changing which list it gets added to by the drop down menu, I can do this:

(Player 1 :: list)
(Player 2 :: list)
add ["3948"] to Player [1]
add ["109"] to Player [2]
add ["2983"] to Player [1]
add ["1092"] to Player [2]

define add (block of text) to Player (Player #)
add (block of text) to (join [Player ] (Player #)

It's quicker to change a bit of text than swapping variable blocks, so it should help when you are duplicating a bunch of blocks that add an item to a list and then changing which list it should go in.

bump, and support. Provides a method of shortening recursive code across different lists as well.

Support. This can save hundreds of blocks in some projects.

Total support! This used to be a hack in 2.0, but it broke with the release of 3.0, this would be very usefull!

Bump.

This isn't getting the attention it deserves!

AlexeyChub wrote:

This isn't getting the attention it deserves!

Likely because it was made a whole year ago, but now it's getting put on the front page again with bumps from the likes of you. Thanks for that!

I see no real downsides to this suggestion. Good job coming up with such an idea!

I support, but there is a small problem with it.

If it was only allowed the join block, it would be confusing because all the other blocks that allow a block as input allow any block to be put in (except booleans, but they have a shape, which sort of shows that you have to put in another block of that shape). It would be better to allow any block to be put in.

I can see why accepting any block might be a problem, because it might be confusing to input a list name when compared to more advanced programming languages that can handle lists inside of lists, where you would input the object of a list itself.

add [thing] to (item (1) of (list v)) //add "thing" to the list with the name of the first item of "list"

add [thing] to (item (1) of (list::list)) //add "thing" to the list stored in the first item of the list named "list"

Both of these problems don't stop me from supporting this suggestion, but if the suggestion is added, we would have to deal with one of these problems, depending on how it is implemented.

What would happen if the variable/list doesn't exist?

In Scratch 2.0, it automatically created a for-this-sprite-only variable defaulting to 0, but a loop could easily spam-create a ton of variables and lag the user.

Also, would there be a way to dynamically get variables? In Scratch 2.0, we used to use the _ of _ block, but not only was it a bit inconvenient to set the second dropdown to the sprite in a different sprite (the dropdown excludes the current sprite), it also didn't work for clones.

Perhaps there could be a “myself” or “this sprite” option in the second dropdown that is always listed and works for clones:

((join [] []) of [myself v])

Sheep_maker wrote:

What would happen if the variable/list doesn't exist?

In Scratch 2.0, it automatically created a for-this-sprite-only variable defaulting to 0, but a loop could easily spam-create a ton of variables and lag the user.
…

I think that by default, 3.0 could opt to NOT create a list every time an invalid list is selected. Also, the spam-creation of variables is kind of on the user – we have run without screen refresh that acts as an optimization but put something like a wait block in there and voila! lag. Though I do agree that this is on a whole 'nother level because of the built-in integration instead of an optional checkbox, but again, ST could make the script not create vars/lists.

Bumpity bomp

More bomps

Another BuMp

bump.

make this happen. this was a hacked block in 2.0 but now i have to do so much for the same result

bump

bump yessss, although scratch doesn't seem to listen to the suggestion forums but this would be great to be re-added

This suggestion is mostly fine but there are problems, which mainly have to do with the fact that you get a variable by name:

> Renaming variables forces you to hunt down and replace every place where the variable is called by name
> Namespace conflicts: two or more different variables or lists could have the same name
> Boundaries: this approach does not let you pass a private variable by reference to a block by another sprite
> Similarity of:

set [var v] to []
set (var) to []

My fix is to pass variables not by name but by an ID which is guaranteed to be unique to the variable. If a sprite is cloned, the private variables of each clone get their own ID. The ID can be obtained with a block:

(id of [variable v])
(id of [list v])

A variable or list can be obtained with a ‘variable with ID ()’ or ‘list with ID()’ reporter. The block will work even if the ID is that of a private variable of another sprite. If the ID does not refer to any currently-existing variable or list then nothing happens.

(Variable with ID ())
(List with ID())
set (variable with ID ()) to []
add [] to (list with ID())
// and so forth

bump

ik it's been a while, but bump and support. Even though there IS a workaround, for projects with lots of variables it could look terrible. Nobody has shown us what you actually need to do, so https://scratch-mit-edu.ezproxyberklee.flo.org/projects/675014756/ Eww. Look at this code! Imagine doing this with 20 or 30 variables.