Add static type support for blocks

[TannerGabriel]

Draft demo for static type support.

Open questions

• Is there a better way to update the getters and setters and the fieldVar_ that they contain?
• The current implementation changes the data structure of the non-typed version (third field with type, which is null or empty if there is no datatype). Would it make sense to keep the data structure unchanged when not using types?
• With the current simple typechecking, if the type is changed, the connection will be split since the blocks cannot be connected anymore (default Blockly check functionality). Maybe we should change this to just disable the input and display a warning (not sure if this can be done when using setCheck)
• Getters and setters display all variables. If we are connected to a specific type, it might be useful to only display the variables with the same type

Current behaviour

Set type in init:

LexicalVariablesPlugin.init(workspace, {
    types: {
      enableDataTypes: true,
      dataTypes: [
        ['int', 'int'],
        ['float', 'float'],
        ['boolean', 'boolean'],
        ['char*', 'String'],
      ],
      loopType: 'int',
      defaultType: 'int',
    }
  });

[TannerGabriel]

Another consideration we need to make is how to handle complex data types like arrays and maps. I have currently thought of three approaches and the current implementation would easily support approaches 1 and 3.

Add all supported types to the types array

Advantages:

• Easy to implement
• Should work for all languages

Disadvantages:

• Confusing and hard to evolve for multiple data types and combinations (e.g. multidimensional arrays, all combinations for maps, etc.)

Recursive field to select base and type

The user can select a type, but the dropdown also contains a list and map option that will enable a second dropdown. This can be repeated recursively to allow for multi-dimensional arrays and other complex data structures. Here is a simple sketch:

Advantages:

• Support all combinations of data types without overloading the dropdown

Disadvantages:

• Not sure if this works for all languages since the structure of types is different
• Complex UI for complex data types (2+ dimensional arrays, nested maps, etc.)
• Complex implementation

Base options + text input

Adding a text input to the dropdown that lets the user specify complex types that aren't in the typelist. For example, if the type list only contains one-dimensional arrays, the user would be able to set the type to a two-dimensional array.

Advantages:

• Simple implementation but still supports all types
• Every time in every language can be added (even very complex types)

Disadvantage:

• Types could be incorrect (user error, should this be acceptable??)

Let me know your preferences or other ideas.

[mark-friedman]

My sense is that the exact set of types that you want are probably going to be fairly specific to the language that is going to be generated and the potential subset of types that the particular Blockly app developer wants to support in their app. Consequently, I think you might want to specify an interface/API that the Blockly app developer has to support and your code uses that to generate the types. That's still somewhat independent of the three basic UI choices that you mention above.

Also note that you (and/or the Blockly app developer) might also want to support "any" types to allow for heterogeneous container types.

[TannerGabriel]

I built a version of this for my own project, but it's tailored closely to how that codebase works. It doesn't generalize well enough to belong in the plugin, so I'm closing this PR.