Variable naming is funky [FIXED]

(Read-only) To re-open a bug, start a new thread in the Bugs forum.

Moderator: MSandro

Posts: 3
Joined: Sep 25th, '15, 22:43

Variable naming is funky [FIXED]

Post by ursulawolz » Oct 17th, '15, 18:46

Opened a new project, dragged the Sprite (Instance?) variable 'n' to the workspace and changed its name to nDifferent. Was unable to refer to it with its new name. "set" and 'increase' didn't record the new name. Dragged a 'set n' block into the workspace and executed it. It was no longer bound to nDifferent.

Also, this is not so much a bug, but confusing. The "set local var to _" block can be included in a script or just executed on the workspace and it does nothing. Perhaps it should not be allowed to drop in the workspace at all?
The variable bubble 'var' can be dragged off of it, changed, and broken the same as a regular variable.

Maybe I'm saying that scoping is as hard as objects and the visual metaphors aren't quit there. I ran into this trying to create a very simple example scoping example in GP for my Friday Night Coders.

Perhaps just reorganizing the menu. Start with the header "Sprite Variables" then "Add variable" block, then have a header "Shared variable" followed by Add Shared variable block. I'm on the fence about the already started variables (e.g. n) . Its confusing. Have a third header "Local variables" and put that block under there?

Finally, Delete variable seems to be asking me to get rid of all references to a variable before I can delete it, however, shared variables loose their value, but the blocks remain, which means I can reuse them without redefining them.

All very confusing. Maybe discuss how this could be improved?

Posts: 5
Joined: Sep 11th, '15, 02:26

Re: Variable naming is funky

Post by Jens » Oct 21st, '15, 10:32

changing the name of a variable getter block does not rename the variable. You can use it to point the variable getter reporter to another variable. If you want to change the field variable "n" to "foo" you need to delete "n" and create a new variable named "foo". Then you can use "rename" on each reporter that refers to "n" to make it refer to the new "foo".

A "local" var is really a temporary variable that only lives inside the script (stack of blocks) that it's inside. It does not become a field of the object.

Posts: 379
Joined: Sep 11th, '15, 14:42

Re: Variable naming is funky

Post by JohnM » Oct 27th, '15, 21:16

There's definitely room for improvement here.

Local variables are extremely useful. They allow the programmer to give meaningful names to intermediate calculations. Used well, this can make code easier to understand and debug as one is writing it and more readable to others. I'd like people to think of local variables like water and use them often.

The way I use local variables is to plop in a "set local var to" block whenever some expression starts getting too long, or when I want to clarify the code to the reader. For example, this edge detect script:
uses a local variable to highlight for "diff" to emphasize the fact that edge detection is based on the magnitude of the difference between adjacent pixels. (Note: you can click on the picture to enlarge it.)

That said, I can see that GP's variables palette can be confusing. It may help to organize the palette as you suggest to emphasize the three kinds of variables. We could also play with the layout -- maybe have three different sections separated by dividing lines.

Posts: 379
Joined: Sep 11th, '15, 14:42

Re: Variable naming is funky [FIXED]

Post by JohnM » Nov 20th, '15, 15:48

This was addressed by reorganizing the variables palette, which seemed to help. Additional wording changes may further improve understanding.