第二部分：
2. GILL为何被设计成这样
起步时有清晰目标是好事情，但在我们这里却不见得十分好。:(
在CSDN (http://www.csdn.net)上讨论时，我们遇到不少观点，比如，人们较为关心这个库能提供什么算法，或者现有的库很不错了，又或者是鼓励的话语，等等。面对如此多的意见，我们三个成员可以没经过什么讨论就达成一致的确有些奇怪。唯一的混乱是papercrane以非常隐晦的方式问Housisong能否接受GILL所需的某种概念，然后后者答曰你说的我早说过了（比较令人尴尬:)）。从ajoo那里我们得知这个概念可称作“protocol”，为ajoo所提出。于是，我们顺理成章的决定用protocol来描述前面提到的三块基石的接口。比较幸运的是我们没有一开始就纠缠于实现什么算法，免于陷入不必要的争吵中。这一切过于顺利，使得papercrane怀疑很快就会有麻烦降临。
下一步该如何？Housisong建议采用protocol canvas，那时用的是另一个名字，而papercrane提议用protocol grid。当然了两个人都认为自己的protocol是最佳方案。现在我们知道每个方案都有优缺点，不过显然当时我们没有意识到。当时的讨论集中于一件事上：应该支持非原始类型(NonPOD)的图像像素吗？
这是个决定性的结论。如果回答是，canvas在进行像素写入时深复制的花销不少。尤其在像素类型拥有成员变量和成员函数，并且这个成员通过像素存取以可写的方式访问成员时，深复制就会发生。例如，读取像素对象，改写成员变量或者调用改写对象的成员函数，然后写回原先的像素中。Grid呢？它可以轻易的得到像素对象的可写引用，可以直接在上面作改写而不会付出额外开销。但如果回答否，canvas和grid看上去就没什么差别，直到后来Housisong发现了grid的缺点。
Grid的自由之处也就是它的缺点。Grid如何能做一些事情：它们必须依赖已经完成的改写动作？请注意“已经完成”的含义。当grid的像素访问函数返回时，它并不了解改写动作是什么。而当改写动作完成时，grid唯一能有所动作的方法是利用grid像素访问函数返回值的析构函数。这时候存在着一个限制：析构函数中不能抛出异常。事实上，根据改写动作所作的事情中包含抛出异常，这样合理吗？无可非议，然而现在被grid所禁止了。但是对于canvas，这一切显得相当自然且没有难度。
与此同时，ajoo提出的观点使得争论更显千头万绪，无从入手。他提出protocol sheet。Sheet可以通过行或列来访问。人们可以先指定行/列，再指定行/列中的哪一格。换句话说，坐标分量x、y可以分离指定。当确定具体哪一格时，sheet便提供如canvas一样的get/set接口。
OK，现在三种protocol混成一团麻了。事实上，ajoo当时提到应该尽可能减少限制，细节可以日后慢慢再谈。不过当时的讨论充塞了太多东西，把我们弄胡涂了。我们都专注于针对效率、优雅和实用的解决办法。
不管怎样，为了找出哪种提议最好，我们还是作三个假设：如果分别选择canvas、grid和sheet，接下来会看到什么事情？首要问题就是配接。实际上，即使没有这三个提议，世上各种图像表示的接口都是不一样的。任何一种提议都得处理这些差异，或者说都需要配接器。经过针对效率和复杂性的深入讨论，我们发现其实仔细设计的话，配接过程只有可忽略的额外开销。
这就对了，既然接口之间转换没有值得一提的额外开销，——自然也包括那三个提议——那么为何不把三个protocol都包括在新的库中呢？算法以canvas、grid或者sheet任一个作为protocol都可以，不同protocol的图像大可以使用配接器来满足调用接口。既然没有全天候最佳，自然需要灵活一些的方案。算法可以选择对它而言最好的protocol。
其时新的库名为GILL，已经放上SourceForge了。当papercrane根据上述讨论结果，开始把canvas和sheet加入GILL时，他发现了一个未解决的问题，之前提到过但当时忘记了。讨论不同protocol之间配接时，我们忽略了一点：改写成员变量和调用改变成员的成员函数（简称成员改变）。
protocol canvas和sheet没有像素数据的直接引用。它们只能先调用“get”把数据读入一个临时对象，在此对象上做完成员改变，再调用“set”把数据从临时对象写回像素中。举个例子：
template<class Im>
void f(Im im)
{
// …
T tmp = im.get(x,y); // 把像素数据读入对象tmp
tmp.foo(); // foo函数会改写tmp
im.set(x,y,tmp); // 从tmp中写回im
}
另一方面，protocol grid具有像素数据的直接引用，如同基于组件架构中的“属性”一般。那实现成员改变可就相当自然了。例如：
template<class Im>
void f(Im im)
{
// …
im(x,y).foo(); // 简洁快捷！:)
}
无论我们选择那种做法，都得兼容别的protocol。例如，如果选择第二种做法，具有canvas protocol接口的图像，被配接成为grid接口，也得适用于这种做法下的算法，不可出现似是而非的结果，比如说成员改变只是在临时对象上，而不是想要的像素数据上产生了效果。那么，我们该如何设计算法f，使之无需考虑各protocol在此问题上的差异呢？
如果跟从canvas用get/set包起来的代码模式，当遇到本质上以protocol grid为接口的图像时就会产生额外开销，这些成员改变本来无需get/set的。
如果跟从grid的代码模式，问题就在于如何在foo调用完毕后调用“set”？很不幸我们不能依赖foo本身，那是像素类型所控制的。想象im(x,y)返回了一个对象，这个对象的析构函数在foo之后调用，看来是个放置“set”的好地方……等等！还记得讨论grid的缺点时提到这会带来什么问题吗？是的，未定义行为的陷阱：“set”或许在析构函数抛异常。
看来简单的跟从现有表达方式是无法解决问题的。当时GILL不得不暂时集中于解决这个问题，直到ajoo提出一个方案，成为protocol mutator。
Protocol mutator把成员改变和具体protocol的耦合分离开来。Protocol canvas/grid/sheet决定如何给出一个名为mutatee的可以改写的对象，在此对象上成员改变能够真实的作用在原先的图像上。给出这个对象之后，mutator才能够对其施加具体的改变。通过这样的手段，成员改变和具体protocol相互没有依赖。如何给出可改写对象的策略可以附在protocol canvas/grid/sheet中。每个protocol都有自己的策略，称为mutatee_adaptor，这东西接受图像对象和mutator对象作为参数，其中封装了调用的顺序和可改写对象如何产生的细节以及差异。下面是一个例子：
template<class Im>
void f(Im im)
{
// …
M ma = im.get_mutatee_adaptor(); // mutatee_adaptor
Mutator mb; // mutator
ma(im(x,y),mb); // 收集mutatee和mutator
}
// …
struct mutatee_adaptor
{
template<class R, class P>
void operator()(R& v, P& p)
{
T obj = …; // 如何给出可改写对象？
p(obj);
// 还有什么要对obj做的？继续做
}
};
补充完这一点，GILL就没有什么太大的问题了，当时发布了稳定版本0.0.2。
