Fields should not be saved separately from inputs

[towerofnix]

The block definition has (among other irrelevant ones) two properties: inputs and fields. These correspond to the two different ways to enter data into a Scratch 3.0 block, i.e. via input or via field.

In the 3.0 editor, "inputs" mean the following (and maybe more):

• Number slots.
• String slots.
• Boolean slots.
• Dropdowns which accept blocks (round dropdowns).

"Fields" usually refer to dropdowns which do not accept blocks (square dropdowns).

In Scratch 2.0, the save format for a block was relatively simple and straightforward: [blockName, ...blockArguments]. blockArguments was simply a list of strings, numbers, and blocks. A block saved as ["mycoolblock", "apple"] simply meant that there was a value "apple" in the first slot, regardless of whether that slot was a dropdown or string slot.

Fundamentally, Scratch 2.0's save format makes it easy to change the behavior of an input without breaking existing projects. As an example, I'll refer to scratchfoundation/scratch-blocks#1418, which reads:

Proposal

Accept reporters to be dropped on the PROPERTY field of the "sensing_of" block:

In 2.0's format, this means toggling a flag somewhere which makes the dropdown accept blocks.

3.0's save format, however, makes this difficult. It would be required to change a field to an input; this does break existing Scratch 3.0 projects, because the save format distinguishes fields and inputs. (In theory and practice, all occurrences of the dropdown which was previously a field lose their data, so the now-input dropdowns are left empty -- they search for data in "inputs" but it is stored in "fields".)

My proposal to allow for changes such as the one described above is to do the following:

Merge inputs and fields together. The unified property should be an object with input/field names (ala PROPERTY, CONDITION) as keys and one of the following as values:

• A string ("Hello, world!") or a number (42).
• A reference to a reporter block, probably saved as something like {"block": "<block ID>"}.

Let scratch-vm assign values to fields or inputs, according to the block definition in scratch-blocks, and have the VM create any necessary shadow blocks. The scratch-parser module would not know whether PROPERTY means an input or a field; instead, the VM would look at the scratch-blocks definition of the block (sensing_of) and see whether there is a PROPERTY input or a PROPERTY field. Then, if necessary, the VM would create required shadow blocks (or anything similar).

Since the parser wouldn't know the difference between text inputs or dropdowns which accept reporters or those that don't, there wouldn't be any difficulty changing between those in block definitions in scratch-blocks, making implementing ideas such as the one suggested above easier and non-destructive.