PyQt挖地雷游戏学习笔记（5）

在game_scene.py的class GameScene中，使用了closure套路。

重点是这一套路的结构形式特点，函数的内容无关紧要。代码如下：

 def inGame(func):    """    check if this game is running    """    def new_func(self, *args, **kw):        if self.status != RUNNING: return        return func(self, *args, **kw)    return new_func#----------------------------------------------@inGamedef toggleFlag(self, pos):    place = self.getPos(pos)    ...    self.update()#----------------------------------------------@inGamedef open(self, pos):    place = self.getPos(pos)    ...

首先，网上普遍把closure直译成“闭包”，十分别扭糟糕。

感觉意译成“缠绕”比较形象，比较恰当。理由如下：

分析一下调用函数open的过程。由于@修饰符的作用，实际调用的是

inGame(open(pos))

函数inGame内没有直接执行的语句，简单返回其内部嵌套的函数名new_func，

于是，开始执行new_func(pos)，

可见，inGame与new_func已经发生“缠绕”。

在内部函数new_func(pos)里，将判断：

if self.status != RUNNING: return

如果棋局并未进行，返回空值，函数open(pos)不会执行；

否则，若棋局正在进行，new_func(pos)返回与其“缠绕”着的inGame管理的对象func，

也就是函数open。于是，open(pos)得以执行。

使用这种互相“缠绕”的函数的语法套路，有必要吗，有实际价值吗？

我觉得，本例的“缠绕”没有多少实用价值，作者的本意大概是为了演示宣传这一语法套路。

但这并不是说，“缠绕”在任何情况下都不实用。

PyQt的槽函数@pyqtSlot()，就是应用了“缠绕”的套路。

估计，目的是为了由函数pyqtSlot()统一管控用户自定义的各式各样的槽函数。