Return

[Wowfunhappy]

I made a significant adjustment to the behavior of custom reporters for the local Scratch instance I use in classrooms. I don't know if this is desirable in TurboWarp, but I wanted to offer the change back upstream.

I did my best to maintain code quality, but I'm not a professional developer, so I apologize if some cleanup is needed.

Resolves

Not Applicable.

Proposed Changes

If every return block connected to a block definition returns a boolean (as in, the _ in every return _ is a hexagon block), the call block will itself become hexagon-shaped, and able to be dropped in boolean inputs.

Block definitions with mixed return types will be ovals. Non-boolean "oval" call blocks cannot be dropped into boolean inputs.

Reason for Changes

In TurboWarp's current return experiment, it is impossible to create boolean hexagonal reporters. As a workaround, TurboWarp allows non-boolean custom reporters to be dropped into boolean inputs, but this runs somewhat counter to how Scratch's type system is supposed to work^†. I rely on the shape system when I teach elementary school students.

Implementation Notes

In order to make this work, I set Blockly.Procedures.blockContainsReturn to run on every block connection/disconnection. I don't love this, but it was the best I could get working on my own. The function is already debounced, and I don't think it's doing anything resource intensive?

However, this has one notable side effect. If you:

1. Attach a call block to a larger script.
2. Add or remove a return from the block definition. (For usability reasons, the instance of the call block you already attached will not change shape.)
3. Detach the call block you attached previously.

...the call block will snap to its updated shape the moment it is detached. As it happens, I greatly prefer this behavior anyway.

Test Coverage

Tested manually. (And not super extensively, but I'm relatively confident nothing will break.)

---

^{† Vanilla Scratch does allow item _ of list and item # of _ in list to be dropped into boolean inputs, but I think this is also kind of bad. It runs counter to the behavior of every other block.}

[GarboMuffin]

Thanks, this is great

The function is already debounced, and I don't think it's doing anything resource intensive?

It will probably be slow in very large projects, but it is tolerable. It will be cleaned up later if it seems to be a problem.

[GarboMuffin]

I noticed that processProcedureReturnsChanged forces a toolbox update, which is generally not very fast, so I've added some commits to only refresh the toolbox when it needs to be

In TurboWarp I would like people to be able to manually change block types and drop reporters anywhere (at least as an option), so I've added two variables in core/procedures.js to configure related behaviors:

• Blockly.Procedures.USER_CAN_CHANGE_CALL_TYPE
• Blockly.Procedures.ENFORCE_TYPES

You may find those useful