Variable Changes

[Rachel Fenichel]

Hey all,

The next push from develop to master will include a major change in how we implement variable management.  From the user side it should be fairly minor, as well as from the developer side.

• Variables can now be explicitly created and deleted.  
  
• The workspace keeps a list of variables, rather than walking the full list of blocks every time a variable dropdown is opened.  
  
• There is a new "Create variable" button in the Variables category.  
  
• There is a "Delete this variable" option in the variable dropdown menu.  
  
• Removing the last use of a variable no longer "deletes" that variable.
  
• For generators: Blockly.Variables.allVariables() still does what you want; Blockly.Variables.allUsedVariables() may sometimes be a better choice.
• The "change [variable] by:" block is now in the variables category instead of the math category.

Motivation: This allows us to implement typed variables in the future, with the type being specified when the variable is created.

For more information, check out these issues on github:

https://github.com/google/blockly/issues/446 (Discussion of new system/specification)

https://github.com/google/blockly/issues/468 (Add events for variables)

https://github.com/google/blockly/issues/518 (Allow the developer to specify undeletable variables?)

https://github.com/google/blockly/issues/558 (Update documentation)

https://github.com/google/blockly/issues/541 (Entertaining interaction of function definitions, variables, and undo/redo)

https://github.com/google/blockly/issues/561 (Disallow variable fields in shadow blocks)

Cheers,

Rachel

[Daaron Dwyer]

Hi Rachel,

These are some very useful changes for me. When can we expect the push?

Cheers,

Daaron

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rachel Fenichel]

Hi Daaron,

There's a team meeting today  and we'll evaluate our code health at that time and either release or else set a release target date.  We've had some regressions in the last few weeks and we're trying to be more careful with this push.  And it's live on develop now if you want to check it out.

Cheers,

Rachel

[Miguel]

Hi,
Why would variable fields be disallowed in shadow blocks?
This seems quite strange to me, given that this is a choice that is entirely on the developer, not on the user.
So why reduce developer's freedom?

Best regards,
Miguel

[Rachel Fenichel]

Hi Miguel,

(Complicated description ahead.)

There are a few nasty edge cases with shadow variables.  For instance: 

The developer includes a shadow block with a variable field in the toolbox, with the name "var" by default.

The user drags that block (A) out of the toolbox, which creates the variable "var"

The user creates a variable named "foo" and selects it in the dropdown

The user drags a block (B) with a variable field over the shadow, and somehow selects "foo" again

The user deletes the variable "foo"

The block (B) containing "foo" will be deleted, and the variable will be deleted.  Then the shadow block (A) will be respawned, and it will have a reference to a variable that doesn't exist.  

The shadow block (A) will refer to "foo", not "var", because it remembers its last state (useful for number and text shadow blocks).

We could make it create the variable when that block spawns, but then deleting a variable can delete a bunch of blocks (B) but not every referring block (A), and the variable isn't actually deleted.  Also, if the shadow block (A) had been left as "var" but the real block (B) had been "foo", deleting "foo" would delete the blocks (A and B) *and* the variable.

The state that determines the outcome is completely opaque to the user, and fundamentally is a problem with variables having references outside themselves.  We tried to find a good way to signal this to the user, and we couldn't find a clean solution that still allowed variable fields on shadow blocks. 

[Rachel Fenichel]

Two bugs to fix before this push: https://github.com/google/blockly/issues/586 and https://github.com/google/blockly/issues/585

[Miguel]

Hi Rachel,

thank you very much for the detailed explanation.

I see the potential problem you presented in the example.

I also understand that you have to develop a set of features that are homogeneous, while people using the library may have conflicting interests.

But, for the sake of the discussion, let me propose two possible "solutions" to this problem:

"Solution A": in my opinion some people will prefer not having to deal with a 'delete variable' command: variables could be managed either the old way or persisting them after use and having a 'clean unreferenced vars' command.

I think the usage of 'delete variable' to delete all the references in the workspace, including occurrences not currently on view, could be problematic.

Not using 'delete variable' would avoid the problem in the example.

"Solution B": Even using the 'delete variable', there should be no problems if the behaviour of the shadow variable blocks would follow the rules 1 and 2 described below.

1. On change, shadow blocks morph to regular blocks.

I know this is an already lost battle, but still a lot of the people using blockly (with shadow blocks) developed or is interested in having this behaviour.

This would solve the problems in the example you described.

But as this would not solve all the potential problems, so I would also implement the following behaviour...

2. On each creation of a shadow block (including respawn), all its variable fields get new unique names (possibly based on a common prefix or template).

I would say that this is the most sensible option in a wide range of cases.

I think users expect default inputs to be pointing to new variables, not existing ones.

In my application I had already 1 in place and I just developed 2, that one was easy (using a very simple behaviour in which for shadow blocks the initial varnames are used as prefixes to which a counter is added).

If using variable fields in shadow blocks will be explicitly forbidden I will have to extend the existing shim to override the check.

Not necessarily a big deal, depending on how the check is coded, but more stuff to maintain in sync with the Blockly version.

Best regards,

Miguel

[Rachel Fenichel]

Hi Miguel,

Unfortunately, we're a pretty small team, so we can't maintain all of the possible configurations of Blockly.  We've decided that having a button to delete all uses of a variable is definitely a use case we want to support, to make it easier for new coders to see the connections between their actions and the results on the page.  This design is a result of following through on that philosophy.  (Trust me, this was not a fast decision.)

Your solution A should be possible with a fairly small shim on your side (skipping this code: https://github.com/google/blockly/blob/develop/core/workspace.js#L312).  Solution B is more complicated and (in my opinion) still has the pitfall of having multiple unexpected things happen when you hit a single button.

Best,

Rachel