Open
Description
This is a piece of technical debt that would resolve many of the variable conflicts we've created patch functions for, because currently, resolving a variable conflict also entails updating variable IDs in all the fields in possibly all the blocks in a project that reference that variable.
If we always maintain the following rules in Scratch 3.0, there should not be a need for fields referencing variables/lists in blocks to have the variable ID (the variable/list should be looked up by name and type instead).
- Within any given block in a sprite, all sprite local variables and all global variables are in scope. Within any given block in the stage, only global variables are in scope.
- There should be no variable references without the referenced variable currently in scope. E.g. all conflicts should be resolved immediately (and not when the conflicting block is executed).
- All variables in scope should have unique names by type. E.g. local variables of type ‘x’ should not conflict with any other local variables of type ‘x’ on the same sprite, or any global variables of type ‘x’. ← Violation of this is what constitutes a ‘variable conflict’
When importing projects from 2.0 that violate any of these constraints, variable conflicts should be resolved in a way that maintains the behavior of the original 2.0 project does not break.