ruby研究学习[1]：参数篇

本专栏，主要挖掘在开发生活中遇到的现实问题，挖掘出来的一些，可能被忽略的知识，并解决可能比较冷门的难点。

Q1: 如何写一个开放的接口，可以适当的修改初始化或跟进处理一些动作，类似于后期绑定？

场景来自于，试图模仿coffee script写一个类，用于处理各种版本的类coffe script问题。1

我在生活中邂逅markdown和coffe script开始为之着迷，但也开始苦恼markdown和coffeescript存在的不够“懒”，不够“个性化”。

其“不懒”在于，依赖一定的工具、平台，为迁移写作环境带来麻烦，每换一台电脑，都要重新部署本地版本。

其“不个性化”在于，有一些个人意见内的要求，很难加入到这两者之间。所以我开始在此开设分支研究，如何创新一个工具，利用如ruby、python等的优势，写一个只需要copy源代码就可以部署的新功能。

[1] 这里是 “>” 引用排版的问题，想要换行写普通文字或者另起一段引用的时候，有些场景下的markdown并不支持，这也是我面临的挑战，以后创造一个个性化的markdown版本，更见丰富，自由化。

---

我们看一个典型的例子，常见的$\le$1.93的ruby定义命名参数和2.0以后的方案

---

目录

class cmdMaching1 # ver <= 1.93
    # add(cmdstr:String, params:ParamArray)
    def add(cmdstr, **params) #->[1]
    end
end
class cmdMaching2 # ver >= 2.0
    # add(cmdstr:String, params:ParamArray)
    def add(cmdstr, somenamedparam:defaultvalue) #->[1]
    end
end

[1]这里可以发现markdown新的不够完善的地方，代码块中，无法插入一些脚注、引用等，只能用折中的办法手动排版了。

其实我们这里可以发现一个问题2 ：markdown 排版缩进很费劲，混杂<p>标签的时候容易出错，而且在很多场合下脚注等常用标志，不能使用。下一段开始，用 硬插入缩进。

---

  如果我们对参数的检查有要求，以保证程序的容错性增强，显然不能通过异常的手段来执行。

  其实程序发展到现在，我们很多程序员还没有一个健全的容错理念。异常是针对系统级错误的手段，很多时候用户级的错误，我们要做的是软处理。所以我有一个习惯，处理错误的时候，用户级会把很多不重要的信息输入进行抛弃或者矫正，以确保程序大部分情况下能执行；对那些敏感或者重要的信息进行警告；影响后期执行的信息才会处理为异常，把程序中断。

  异常机制可以让很多入门程序员偷懒，在学习深造上停止不前。但异常不是万能钥匙，我们很多程序不够流畅，就是因为异常太多，甚至很愚蠢的嵌套很多，不停的抛给下一个函数，但结果都没有妥善处理。

  这里就是针对异常问题，我们需要动的手术，如何巧妙的对一些不影响用户或者后期程序员的轻量级错误，进行矫正，而不是抛出异常，卡住等。这里更为前瞻的考虑是，后期程序员可以再度修改这种容错代码。这也是ruby、python、javascript等语言最富有魅力的角度之一！
  我为此采取的方案是：初级对错误的参数进行默认值修改；后期程序员可以用yield对我的修改方案进行替代处理。实现起来就是：
目录

class cmdMaching1 # ver <= 1.93
    # add(cmdstr:String, params:ParamArray)
    def add(cmdstr, **params) #->[1]        
        if block_given? then
            yield(params)
        else
            params = {:aParam:1,:bParam:2}
        end
    end
end

# 后期程序员
acmd = cmdMaching.new
acmd.add { |params|
    params[:aParam] = params[:aParam].to_i
    params[:bParam] = params[:bParam].to_i
}

目录

---

1. 这个场景引发了很多设想，实现过程中激发了很多新的问题。此处是第一处。 ↩
2. 此处暴露了markdown的脚注和缩进不能兼得的问题。 ↩