Maximouse wrote:

What about local lists?

create variables (local variable :: #ffb366) (local list :: list) {
set [local variable v] to (10)
add (local variable) to [local list v]
} :: variables

DrGaming_92Games wrote:

Maximouse wrote:

What about local lists?

create variables (local variable :: #ffb366) (local list :: list) {
set [local variable v] to (10)
add (local variable) to [local list v]
} :: variables

That's an interesting idea, you should make your own topic so this can get discussed more directly.

Maximouse wrote:

DrGaming_92Games wrote:

Maximouse wrote:

What about local lists?

create variables (local variable :: #ffb366) (local list :: list) {
set [local variable v] to (10)
add (local variable) to [local list v]
} :: variables

That's an interesting idea, you should make your own topic so this can get discussed more directly.

I'm not sure if this could be a separate topic because it requires the block suggested here. I think that suggestions should be independent of each other.

DrGaming_92Games wrote:

bump, and @Maximouse, thank you for the images, those were really helpful and I forgot to thank you earlier. After having thought about the look of the local variables, I think that a different color may not fit with Scratch. And also, what if another global or sprite only variable is defined, what happens to the local variables. Does the local definition take precedents? Should you just not be able to make a global variable with the same name as a local variable? Feedback is appreciated.

repeat (83)
create variable (var) (+:: grey) {
. . .
} :: variables
end

when green flag clicked
say (input :: custom)
define func (input)

HTML-Fan wrote:

I thinkt that it's a good idea. A problem: Currently you can drop function parameters outside of the function:

when green flag clicked
say (input :: custom)
define func (input)

define func (parameter) (another parameter) (parameter) 

create local variable named [] :: variables
(local variable: [] :: variables)
delete (localvar v) :: variables

create local lists (local list :: list) (+ :: grey) {
add [Hi man!] to [local list v]
say (item (1 v) of [local list v] :: list)
} :: list

DrGaming_92Games wrote:

I thought of a problem: visually telling the difference between local variables and normal variables. I have 2 ideas for this, either make the local variables a lighter orange, or add a little icon next to it the same way cloud variables do (obviously with a different symbol).

(item (item number of [variable name] in [varNames v]::list) of [varVals v])

(variable name)

scratchastroLOL wrote:

but i don't really understand why it should be a C block.

create local variable named [] :: variables
(local variable: [] :: variables)
delete (localvar v) :: variables

and local lists

create local lists (local list :: list) (+ :: grey) {
add [Hi man!] to [local list v]
say (item (1 v) of [local list v] :: list)
} :: list

create variable (a) {
set [a v] to (11)
}::variables
...
create variable (a) {
change [a v] by (1)
say (a)
}::variables

whiteandblackcat wrote:

DrGaming_92Games wrote:

I thought of a problem: visually telling the difference between local variables and normal variables. I have 2 ideas for this, either make the local variables a lighter orange, or add a little icon next to it the same way cloud variables do (obviously with a different symbol).

I agree; they'd need to be a bit different. I like a lighter orange, but that might be difficult in terms of getting local variable blocks confused with variable blocks and/or control blocks. Perhaps an icon would be better, although I have no idea what you would use.

whiteandblackcat wrote:

Also @Maximouse - nice mockups, but if you set it that you have to create the variables beforehand, then you may as well not have temporary variables. Isn't the whole point of most suggestions of this kind that you can name them? So perhaps it would be better for the C block to have an editable input, so you can make a new variable named whatever you need it to be.

whiteandblackcat wrote:

Also, if you had

create variable (a) {
set [a v] to (11)
}::variables
...
create variable (a) {
change [a v] by (1)
say (a)
}::variables

what would this return; 11 or 1? There may be no reason to code like this, but scratch needs to know how to respond.

create variable (a) {
set [a v] to (11)
create variable (a) {
change [a v] by (1)
say (a)
} :: variables
say (a)
} :: variables

Maximouse wrote:

whiteandblackcat wrote:

Also @Maximouse - nice mockups, but if you set it that you have to create the variables beforehand, then you may as well not have temporary variables. Isn't the whole point of most suggestions of this kind that you can name them? So perhaps it would be better for the C block to have an editable input, so you can make a new variable named whatever you need it to be.

I don't understand exactly what you want to say – the point was that this block would not appear in the palette because that could be confusing – instead it would be an option in the Create variable dialog.

whiteandblackcat wrote:

what's the point of it then? You may as well just make a normal variable, which is less confusing.

Maximouse wrote:

whiteandblackcat wrote:

what's the point of it then? You may as well just make a normal variable, which is less confusing.

You can create multiple local variables with the same name, used in different places. They don't appear in the palette. And so on.

whiteandblackcat wrote:

Maximouse wrote:

whiteandblackcat wrote:

what's the point of it then? You may as well just make a normal variable, which is less confusing.

You can create multiple local variables with the same name, used in different places. They don't appear in the palette. And so on.

I don't see a point of that.

create variable (local variable) {
} :: variables