Statically typed variable support

[TannerGabriel]

I'm building a Blockly-based application that generates code for statically typed languages like C and TypeScript. This requires rewriting the variable and function block definitions to support variable types. Would there be any interest in adding this functionality to the repository?

[YashSachdeva]

This is a great idea! I'd love to contribute to implementing statically typed variable support. Do you have any initial thoughts on how you'd like the types to be represented in the UI? Dropdowns or user input? I can help with block definition updates and generator logic for C/TypeScript.

[mark-friedman]

This would be a great addition, @TannerGabriel and @YashSachdeva! I don't have quite the time right now to work on this, but if you had questions, and ultimately a PR, I would be happy to try and provide answers and do a code review.

[TannerGabriel]

@mark-friedman I’m planning to implement this. My current thought is to add a type field to single‐item blocks, and otherwise include the type field inside the mutator (see screenshots).

For blocks with multiple variables, like procedures or multi‐variable definitions, I’ll need to store the variable types in extraState, since the fields are FieldTextInput and only save strings (so I can only save the name here and not add another field).

The types will then be passed to FieldLexicalVariable, so its getters and setters can perform type checks later.

I’d like to make the types publicly configurable, so plugin users only need to supply a mapping of correct types for their language. For loops, I think assigning a sensible default datatype should suffice, without a dedicated type field.

Does this sound right, or do you have any suggestions? Also, would you prefer toggling types on the existing blocks or creating separate typed block variants?

[mark-friedman]

plugin users only need to supply a mapping of correct types for their language.

Where would that mapping be supplied? Maybe as an option in the plugin init function? And do you really mean a map or just a set?

For loops, I think assigning a sensible default datatype should suffice, without a dedicated type field.

That seems reasonable, at least initially.

would you prefer toggling types on the existing blocks or creating separate typed block variants?

Good question. I would not be expecting users of the plugin to want to mix and match the typed and untyped variants, so having this be a declared option when initializing the plugin might make sense. I think that that means that there wouldn't be a toggle, if that's what you meant. That begs the question of how that option that I'm talking about would used by the block and field definitions. I guess that if there is a lot of shared code between the types and untyped versions of the blocks and fields then I would maintain a single version of those blocks and fields and would use the option to control their behavior. If the typed and untyped versions were significantly different, then I think I would suggest having separate variants (still factoring out common code for the variants whenever possible).

[TannerGabriel]

I created a draft PR (#75) that tests the functionality and shows what an implementation could look like. It uses the same block definitions as the non-typed variant, and users can enable and set types via parameters passed to the init function. I’ve added several questions in the PR comments and would appreciate feedback before I continue with the implementation @mark-friedman .

[mark-friedman]

I’ve added several questions in the PR comments and would appreciate feedback before I continue with the implementation

I'll take a look.

[TannerGabriel]

@mark-friedman Did you find some time to take a look?

[mark-friedman]

Sorry, @TannerGabriel. I'll really try to find some time early this week to take a look!