图形化编程中的"帽子"积木
内容提要
本文讨论了图形化编程中的“帽子”积木，以及如何将Scratch插件迁移到Snap!中。在Scratch中，“帽子”积木用于响应事件，而在Snap!中，使用通用的“帽子”积木来接受有返回值的积木作为参数。文章还介绍了如何将micro:bit插件中的“帽子”积木迁移到Snap!中，并讨论了使用状态流和事件两种方式来处理外部设备的输入数据。最后，文章提到了MicroBlocks中处理buffer的方式。
延伸解读
从“帽子”积木看图形化编程的设计差异
Scratch允许开发者自定义“帽子”积木，而Snap!、MicroBlocks和GP则采用通用“当(when)”积木，接受返回布尔值的积木作为参数。这种设计将“帽子”抽象为“when + reporter”，降低了积木类型的复杂度，但也意味着迁移Scratch插件时，需要将原本的“帽子”积木拆解为条件判断与通用“当”积木的组合。
状态流与事件：两种处理外部输入的思路
Scratch插件常采用状态流风格，外部设备持续发送状态数据，插件不断读取最新值。这种方式适合陀螺仪等连续数据，但对按钮按下这类离散事件效率较低。事件风格只在状态变为true时发布事件，其余时间保持沉默，减少了不必要的数据传输和处理。micro:bit more插件即采用事件风格，并通过时间戳判断事件是否已被处理。
缓冲区视角：理解变量在插件中的作用
文章将存储外部输入数据的变量视为缓冲区，帽子或predicate积木根据缓冲区内容做出判断。在Scratch/Snap!插件中，单一变量通常足够，因为处理速度快于外部输入。但当数据进入快于消耗时，需要更复杂的缓冲区，如MicroBlocks使用环形缓冲区处理网络消息。这一视角有助于将具体实现与计算机领域的缓冲区概念联系起来。
迁移插件时需注意的状态管理
将Scratch插件迁移到Snap!时，需处理“帽子”积木的持续运行特性。在Scratch中，状态变量常挂在this上；在Snap!中，可使用块变量在积木多次运行间保持状态。对于事件处理，时间戳是判断事件是否被访问过的常用方案，而清空事件槽是另一种方案。MicroBlocks的UDP库采用清空风格，无法与“当(when)”积木配合，而wifi广播库则使用标记变量，可与“当(when)”配合。
Q&A
Scratch 和 Snap! 中的“帽子”积木有什么区别？
Scratch 中的“帽子”积木用于响应事件，通常由事件触发；而 Snap! 不允许用户自定义“帽子”积木，而是提供一个通用的“当(when)”积木，它接受一个返回布尔值的积木（reporter 或 predicate）作为参数，当返回值为 true 时执行下方的积木。Snap! 的设计理念是 hat = when + reporter。
如何将 Scratch 中 micro:bit 插件的“当按下 A 按钮”积木迁移到 Snap!？
可以复用 micro:bit 的固件，因为固件会持续发送状态信息。在 Snap! 中，通过 BLE 连接 micro:bit 并订阅广播，将收到的状态信息存入变量 mb_notify_datas（只保留最近一条）。然后创建一个 predicate 积木“查看 A 按钮状态”，与“当(when)”积木组合，实现“当按下 A 按钮”的功能。
状态流和事件两种方式在处理外部设备输入时有什么不同？
状态流方式下，外部设备持续发送状态数据（如每秒数十次），系统不断读取最新状态；事件方式下，只在特定事件发生时（如按钮按下）发送一次通知，其余时间保持沉默。事件方式更高效，适合传递离散事件；状态流适合连续数据（如陀螺仪）。
在 Snap! 中如何处理事件的时间戳以避免重复触发？
在 Snap! 中，可以使用块变量（block variable）来保存上一次事件的时间戳。当帽子积木在循环中运行时，每次检查事件的时间戳是否与保存的不同，若不同则触发并更新块变量。这种方式简单有效，类似于 Scratch 中在 this 上存储状态变量。
MicroBlocks 中处理缓冲区有哪些不同风格？
MicroBlocks 有两种风格：一种以 wifi 广播库为代表，使用两个变量（一个标记消息是否已读，一个存储最后消息），多次点击积木会重复返回最后消息；另一种以 UDP 库为代表，只用一个变量存储数据包，读取后清空，再次运行返回 false。后者无法与“当(when)”积木配合使用。
为什么说变量在计算中至关重要？
变量（memory）是计算中最重要的两个要素之一，另一个是移动读写头，它们共同构成图灵机。摆弄变量相当于读写图灵机的纸带，因此变量在计算中具有基础性地位。
