It would be helpful for certain projects, such as Aptly, for block types to have fixed semantics regarding whether they are value or statement blocks. Every block in the system follows this with the exception of the component_method and component_set_get blocks, which determine their semantics based on their mutation, and component_method further by having to look up the method definition to determine whether it returns a value or not. It would be better if we codify the value/statement semantics into the block types themselves so we don't have to rely on the mutation to determine the shape of a block. This may need to be done to switch over to the JSON representation for Blockly from the XML representation.
@BeksOmega I'm not sure if my understanding around the JSON serialization is correct, so if you could confirm or deny my thoughts about that I'd appreciate it.
It would be helpful for certain projects, such as Aptly, for block types to have fixed semantics regarding whether they are value or statement blocks. Every block in the system follows this with the exception of the component_method and component_set_get blocks, which determine their semantics based on their mutation, and component_method further by having to look up the method definition to determine whether it returns a value or not. It would be better if we codify the value/statement semantics into the block types themselves so we don't have to rely on the mutation to determine the shape of a block. This may need to be done to switch over to the JSON representation for Blockly from the XML representation.