SmaCC 指南

这是一个用于演示一些SmaCC(Smalltalk编译器的编译器)的简要指南。在这个例子中,我们会逐步开发一个简易的计算器。

如果你已经做过这种东西,你可以先 载入代码 。你载入了代码之后,你需要打开SmaCC解释器生成器。在VisualWorks 和 VisualAge中,它在Tools菜单下。Dolphin的在一个额外的工具目录中。它会打开一个类似下面的窗口:

SmaCC Window

我们第一个计算器相对比较简单。它只要能读取两个数字并把它们相加。开始之前,我们首先要告诉扫描程序如何辨认一个数字。数字由一个或多个数字打头,后面可能还有一个小数点加上0或者更多的数字。扫描程序对这个标记的定义是:

把这行代码输入界面上的scanner标签页中。让我们逐个看每一个部分:

<number>

指出记号的名字。在<>中的名称必须是合法的Smalltalk变量名。

:

分隔记号名称和记号定义。

[0-9]

匹配任何一个在’0’到’9’(一个数字)范围中的字符。

+

匹配前面的表达式一次或多次。在这种情况下,我们要匹配一个或多个数字。

( … )

标示子表达式组。

\.

匹配 ‘.’ 字符(. 在正则表达式中有特殊的含义,使用 \ 来转义)。

*

匹配前一个表达式零次或多次。

?

匹配前面的表达式零次或一次。(也就是,前面表达式是可选的)。

;

终止一个记号说明。

我们不想去关心我们语言中的空白符,所以我们需要定义什么是空白符并且忽略它,输入下面的记号说明:

\s 会匹配任何空白字符(空格、制表符、换行、回车等等)。然后我们怎么告诉扫描程序去忽略它呢?
如果你看一下SmaCCScanner类,你会发现一个叫做’whitespace’的方法。如果一个扫描程序有一个方法的名称和某个标记一样,那么一旦扫描程序匹配了这类标记就会调用这个方法。正如你所见,whitespace方法会吃掉空白符。同样还有一个’comment’方法会作类似的处理。

说到我们的语法,现在让我们来定义它吧。在Parser表格中输入以下语法说明:

这基本上指出了一个表达式可以是一个数字或者是另一个表达式加上一个数字。

我们现在应该可以编译一个分析器了。切换到Compile标签页。你要输入扫描器和分析器的类的名称。这里我们相应使用CalculatorScanner 和CalculatorParser。当类名输完之后,我们就准备编译分析器了。点击 ‘Compile LARLR(1)’
按钮(你应该总是点这个按钮除非你知道你要做什么。一般来说,他会生成比另一个选项更小的分析器)。这时就会生成新的CalculatorScanner和CalculatorParser的Smalltalk类同时会编译这两个类中的一些方法。所有的SmaCC编译出来的方法会按照”generated-*”的格式。你不可以更改这些方法因为每次你重新编译他们都会被覆盖。

不管SmaCC何时创建新类,这些类都会被放到默认的应用程序/包中。如果你使用的是VisualAge,你要确保默认应用程序是开放的版本而且SmaCCRuntion应用程序已经安装(prereq)。

如果你已经生成了扫描器和分析器类,你可以通过类名旁边的”…”按钮来载入他们的定义。如果在出现的对话框中你回答”Yes”,那么在Scanner/Parser标签页中的文本就会被替换为上一次编译过的定义(假设”Generate definition comments”在上一次编译中被选中了)。

现在我们要测试我们的分析器了。进入“test”面板,输入“ 3 + 4”(不要加双引号),并且点击“parse”按钮;你会看到分析器正确分析了它。如果你点击“Parse and Inspect”你会看到一个检视器(inspector),里面有一个包含了被解析的记号的顺序集合(OrderedCollection)。这是因为我们没有指明当分析器在解析的时候要怎么处理记号。你也可以是如一个不正确的内容。例如尝试解析“3 + + 4”或者“3 + a”。应该会出现一个错误信息。

现在我们要定义当我们分析我们的表达式的时候要产生的动作。当前的情况是,我们的分析器仅仅验证表达式是一些相加的数字。一般来说你要创建一些结果来表示你已经解析了什么内容(比如,一个棵分析树)。然而,在这个情况下,我们不关心结构,我们只关心结果(表达式的值)。在我们的例子中,你需要把语法定义改成如下:

括号中的文本是Smalltalk代码,当应用规则的时候,就会执行这个代码。有一个数字的字符串会被替换成相应的解析节点。在第一个Expression的规则中,’1’会被替换成匹配Expression的ParseNode同时’3’会被替换成匹配Number的ParseNode。在规则中的第二个东西是’+’记号。因为我们已经知道它是什么了,所以我们对他不感兴趣。编译新的分析器。现在当你从Test面板中执行’Parse and Inspect’时,你应该看到这个结果:7。

前面的代码有一个问题是如果你需要更改一个规则,你可能也要跟着修改规则内的代码。例如,假设你你在规则的开头添加了一个新的记号,那么你就要更改所有在Smalltalk代码中的引用了。我们可以通过使用命名表达式来减少这种问题。在规则的每个部分后面,我们可以指明它的名称。名称是通过单引号来标明的,它同样必须是一个合法的Smalltalk变量名。象下面这个:

它和前面解析的语言的结果是一样的,但它同时让你更容易维护的你分析器。让我们现在扩展我们的语言并加入减法功能。这里是新的语法:

你编译了这个代码之后,’3 + 4 – 2’就会返回’5’了。下面,再让我们加入乘法和减法:

这时我们遇到一个问题.如果你计算” 2 + 3 * 4“,最后的结果将是 20。这个问题是因为在标准的数学中,乘法比加法有更高的优先级。我们的语法是严格按照从左到右的方式运算的。这个问题一般的解决方法是定义加法的非终结符来强制计算的顺序。这个解决方法的语法类似:

这时候如果你编译这个语法,你会看到” 2 + 3 * 4 “的计算结果是14,正如我们所期望的那样。现在,正如你可以想象的,当优先级规则的数量增加时,语法也越来越复杂(例如,C语言)。我们可以使用歧义语法和优先级规则来简化这种情况。这里有一段使用优先级来限制计算顺序的一段语法:

注意我们更改了语法所以操作符两边都是Expression。我们在语法顶部添加的两行表示“+”和“-”是从左至右运算的而且优先级相同,同时他们的优先级比“*”和“/”低。类似的,第二行表示“*”和“/”有同样的优先级。这个形式的语法通常更加直观,特别是当有很多优先级要处理的时候。我们再来一个例子,现在加入指数运算和括号:

当你编译了这个语法之后,你就可以正确计算” 3 + 4 * 5 ^ 2 ^ 2“得到2503了。由于这个指数操作是右结合的,所以这个表达式是象这样计算的3 + (4 * (5 ^ (2 ^ 2)))。我们也可以计算带括号的表达式。例如,计算 ” (3 + 4) * (5 – 2) ^ 3 “将得到189。

为什么继承是有害的?

通过把具体的基类转变成接口来改进你的代码

作者:Allen Holub  翻译:ShiningRay @ Nirvana Studio

摘要

大多数优秀的设计师避免出现继承(extends描述的关系),就像躲避瘟疫似的。你的代码80%应该完全以接口的方式来书写,而不是继承具体的基类。其实,Gang of Four 这本关于设计模式的书(以下简称GoF)很大程度上关于如何把类继承转变成接口实现。本文将叙述为什么设计师们会有这种古怪的信条。(2,300 words;2003 年 8月 1日)

译注:本文其实已经有人翻译,当时没有具体了解就开始翻译了,如果另一位译者看到这篇文章,希望不要理解为我抄袭的。

extends关键字是很有害的;也许不仅仅是在Charles Mason的级别上,还坏到了只要可能都应该避免的程度。GoF中详细讨论了把类继承(extends)如何转变成接口实现(implements)。

优秀的设计师的大部分代码都是根据接口写的,而不是根据具体的基类。本文将会讲述为什么设计师们会有这种古怪的癖好,同时也将介绍一些基于接口的编程基础。

接口 VS 类

我曾经参加了一个Java用户小组会议,那次刚好是James Gosling(Java的发明者)作特邀演讲人。在那次难忘的Q&A对话(提问)上,一个人问他:“如果你可以重新将Java搞一遍,你会做哪些修改?”“我会去掉类,”他回答道。在笑声渐渐消失之后,他解释了真正的问题不是类的本质,而是类继承(extends关系)。接口实现(implements关系)却是完美的。只要有可能,你们就应该避免类继承。

弹性的丧失

为什么你应该避免类继承?第一个问题是明确的使用具体类的名称会把你框在特定的实现中,让以后的更改会十分困难。

当代,敏捷开发方法学的核心是设计和开发同步。你在完全详细描述程序之前,就开始编写代码了。这种技术完全违背了传统的理念——设计应该在编程之前完成——但是很多成功的项目已经证实了,用这个方法,你可以比传统流水线作业更快速地开发高质量的代码(同时付出很有效)。然而,在并行开发的核心是,弹性的概念。你必须以这种方式来写你的代码,以便你可以尽可能以无痛的方式加入新发现的需求到现有的代码中。

你只要实现确实需要的特性,而不是实现那些可能需要的特性,但要用一种可以适应变化的方法。如果你没有这种弹性,并行开发明显是不行的。

接口编程正是这个弹性接口的核心。要了解为什么,先让我们看看如果你不使用接口会发生什么。考虑以下代码:

现在假设一个紧急的新需求,需要进行更快速的查找,已经暴露出来了,这样LinkedList就达不到要求了,你就要把它换成HashSet。在现有的代码中,因为你必须同时修改f()还有g()(它用一个LinkedList作为参数),因此更改不是局限在一处的,还有一切传列表给g()的地方。

现在把代码改成这样:

现在我们要把链表改成哈希表就只把new LinkedList()改成new HashSet()。就完成了。不需要更改其他的地方。

另外一个例子,比较一下代码:

以及:

g2()方法现在遍历Collection的派生对象以及你从Map中得到键和值。事实上,你可以写一个不断产生数据的迭代子而不是遍历一个集合。你可以写很多不同的迭代子,比如可以从测试台中或者一个文件中不断给出信息。这就是这里最重要的弹性所在。

耦合

关于类继承的一个更加关键的问题是耦合——程序中不期望的一个部分对另一个部分的依赖。全局变量提供了一个经典的例子来说明为什么强耦合会造成很多问题。例如,如果你更改了全局变量的类型,所有使用这个变量的函数(也就是,对这个变量有耦合)就会受到影响,这样所有这样的代码必须被检查、修改和重新测试。此外,所有使用这个变量的函数也会通过这个变量产生耦合。也就是,一个函数可能会不正确地更改了这个变量从而造成了其他函数的行为,如果变量的值在某些特殊的时间被更改的话。这个问题在多线程的程序中特别突出。

作为一个设计者,你应该力争做到最低的耦合度。当然你不可能完全消除耦合,因为一个类的对象调用另一个对象就是一种松散耦合的形式。你不可能写出一个一点耦合都没有的程序。尽管这样,你可以通过绝对服从OO的原则(最重要的是一个对象的实现细节应该对使用它的对象是隐藏的)来相当可观地最小化耦合。例如,一个对象的实例变量(非常量的成员字段),总是应该为私有private。这没有任何例外的情况(你可以偶尔很有效地使用protected方法,但是protected实例变量是相当讨厌的)同样的原因,你也绝不能使用 set/get 函数——他们只是另一种让字段变成公共的稍复杂方式而已。(虽然返回处理过的对象而不是一个基本类型的值的访问函数在某些情况下还是合理的,如果返回的对象的类是设计中的一个关键的抽象的话。)

这里我不是在卖弄学问。我发现了一个OO方式的严格性、快速代码开发、和简单的代码维护之间的直接的相关性。无论什么时候我违反了一个核心的OO原则比如隐藏实现细节,我只能结束代码的修改(通常是因为这个代码不可能进行调试)。我没有时间重写程序,所以我只能遵循这些规则。我关注的是完全实际的内容——我对为了设计而设计没有兴趣。

脆基类问题

现在,我们把耦合的概念应用到继承上。在一个使用实现-继承系统中,派生类对基类有十分紧密的耦合,同时这个闭合的连接是不受欢迎的。设计师们因此给这种行为起了一个绰号——“脆基类问题”。基类是被认为十分脆弱的,因为你可以通过一个表面上十分安全的方法修改一个基类,但这个新的行为,当被派生类继承的时候,可能会造成派生类运行出错。你不能简单孤立地通过检查基类的方法来判断你对基类的改变是不是安全;你也必须查看(并测试)所有的派生类。此外,你必须检查所有同时使用了基类和派生类对象的代码,因为这些代码可能会被新的行为所破坏。对关键的基类的小小的改变都会导致整个程序无法运行。

我们来一起检验这个脆基类和基类耦合这两个问题。下面的类扩展了Java的ArrayList类,来模拟栈的行为:

甚至像这样简单的一个类,都存在着问题。思考一下如果用户利用继承直接使用ArrayListclear()方法来把所有的元素都从栈中弹出去,会发生什么:

这个代码可以成功地编译,但是由于基类并不知道任何关于栈指针的信息,Stack对象现在处在一个不确定的状态。下面再调用push()会把新的条目放到索引2种(栈指针stack_pointer当前的值),这样栈看上去就有三个元素了——但底下两个已经被垃圾收集了。(Java类库中的Stack类就是这种问题,所以不要用)

对于不需要的方法继承,一种解决方式是,对于Stack要重写所有ArrayList的可能修改数组状态的方法,这样覆盖的函数可以正确处理栈指针或者抛出一个异常。(removeRange()方法是一个较好的抛出异常的候选。)

这个方法有两个缺点。第一,如果你覆盖所有的东西,基类就实际上成为了一个接口,而不是一个类。如果你不使用任何继承的方法,类继承就毫无意义。 第二,也是更为重要的一点,你并不希望一个栈能支持所有ArrayList的方法。比如,那个讨厌的removeRange()方法没什么用处。实现一个没用的方法的唯一合理的方式,就是让他抛出一个异常,这样他就不可能被调用了。这个方法却将一个编译时错误变成了运行时错误。这并不好。如果方式只是没有被声明,那么编译器会直接扔出一个“未找到方法”的错误。如果这个方法存在但是他抛出异常,你就不会发现错误直到程序运行的时候。

一个更好的解决方法是封装一个数据结构而不使用继承。这下面是一个Stack的改进过的新版本:

目前为止还不错,但是还要考虑到脆基类的问题。让我们假设你想创建一个Stack的变体,可以跟踪运行一段时间之后栈出现过的最大值。一种可能的实现如下:

新的类运行得很好,至少目前这样。但不幸的是,代码暴露了push_many()方法是通过调用push()来完成它的任务的。首先,这个细节看起来还不算一个糟糕的选择。他简化了代码,同时你可以获得派生类的push()版本,即使当Monitorable_stack是通过一个Stack类型的引用也能完成,所以,high_water_mark的更新是正确的。

某一天,有个人也许会运行一个测试工具并且发现了Stack还不够快,而且他要被频繁地使用。你可以重写一个不使用ArrayListStack,由此改进Stack的性能。下面是最新的版本:

注意push_many()不再是重复调用push(),而是采用了块传送。新版本的Stack运行很好;事实上,它要比原先的版本更 。但很不幸,派生类 Monitorable_stack 就不能再正常工作了,因为如果调用的是push_many()那么他不能正确跟踪栈的使用情况了(派生类的push()版本不再被继承了的push_many()所调用,所以他不会再更新high_water_mark)。现在Stack就是一个脆基类。正如上面显示的,事实上不可能仅仅靠小心就能消除这类问题。

值得注意的是如果你使用接口继承,就不会有这种问题,因为不会继承任何功能,就不会产生不良影响。如果Stack是一个接口,同时通过Simple_stackMonitorable_stack来实现,那么代码就会更加强壮。

在表0.1种,我提供了一个基于接口的解决方案。这个方法和类继承的方法有相等的弹性:你可以根据Stack抽象来写你的代码而不用担心你要具体处理那种类型的栈。由于这两种实现都必须提供公共接口中的所有方法,要出现问题也很难。我也有且仅有一次从写相同的基类代码中获益,因为我使用了封装而不是派生。从负面,我必须通过一个封装类中的细小的访问器方法去访问默认的实现。(例如Monitorable_Stack.push(...)(41行)必须要调用Simple_stack的中等价的方法。)程序员总是抱怨写这种一行就完了的代码,但是仅仅就写这么额外的一行的代价就可以消除潜在的巨大Bug。

表 0.1. 使用接口消除脆基类

框架(Frameworks)

关于脆基类的讨论如果不提到基于框架的编程,就不会是完整的讨论。像MFC(微软基础类库)这种框架已经成为一种建立类库的流行手段。虽然MFC正在急流勇退,但MFC的结构已经深深扎根在无数微软的车间——这里面的程序员都认为微软的方法就是最好的方法。

一个基于框架的系统,一般都是以半成品类的库作为起始,这些半成品的类不会完成所有事情,而是要依赖于派生类提供未完成的功能。Java中的一个典型的例子就是Componentpaint()方法,它其实只算一个占位符;而派生类则必须提供真正的版本。

你可以,但是一个整个类框架都依赖于基于派生的自定义是极其脆弱的。基类也很脆弱。当我用MFC编程的时候,每次微软发布一个新版本的MFC,我都必须重写自己的应用程序。代码会经常编译但接下来却不能正确工作因为一些基类的方法改变了。

所有的Java包都可以即开即用(Out of box)且运行良好。你无需扩展任何东西来让他们执行功能。 即开即用的结构比基于派生的框架要好。它更容易维护和使用,并且即使Sun提供的类改变了他的实现也不会让你的代码处于危险中。

脆基类的总结

一般来说,最好能避免继承具体基类和extends关系,而使用接口和implements关系。凭我的经验,代码中最少有80%应该是完全用接口的方式来写。比如,我从来不引用一个HashMap ;我通常会用指向Map接口的引用。(这里的“接口”是广义的。一个 InputStream也算一个有效的接口,你可以看看是如何使用它的,虽然他在Java中是描述为一个抽象类。)

你加入越多的抽象,弹性就会越好。在今天的商业环境中,通常在程序开发时需求就在不断变化,弹性是十分必要的。 此外,大多数敏捷开发方法(比如Crystal方法和极限编程)完全不能正常运作,除非代码是先用抽象写得。

如果你仔细研究Gang of Four的模式,你就会发现他们中很多都是提供了各种消除类继承的方法,而偏重于使用接口,这也是大多数模式的一个共性。我们一开始就要明白一个重要的事实:模式是被发现的,而不是被发明的。当你看了那些写得好的、易于维护可以很好运行的代码,模式自然就会浮现出来。这告诉我们这么多优秀的代码都会以各种方式避免类继承。

本文是从我即将发表的书中节选出来的,书暂时命名为《 Holub on Patterns: Learning Design Patterns by Looking at Code 》,将会在今年秋季通过Apress (www.apress.com)出版。

关于作者

Allen Holub 从1979年开始从事计算机产业的工作。他目前是一个顾问,通过对行政人员提供建议、培训以及设计、编程服务,来帮助企业不需要再软件上浪费钱。他撰写了8本书籍,包括 Taming Java Threads (Apress, 2000) 和 Compiler Design in C (Pearson Higher Education, 1990), 并且在加州大学伯克利分校教学。请在他的网站 ( http://www.holub.com ) 查询更多关于他的信息。


资源

JavaScript Templates

翻译:ShiningRay @ Nirvana Studio

(译者:JsWiki的第一个版本是用ASP+JavaScript写的,中间就用到了它)

对于Web应用的开发者,来自 TrimPathJavaScript Templates 模版引擎是一个轻量的 APL / GPL 开源 组件,他让你的程序运行在Web浏览器中的时候可以直接基于模版编程(像PHP/ASP/JSP)。

  • The JST 引擎是完全用标准JavaScript写成的。

  • 他支持一套丰富的模版标记语法,和FreeMarker, Velocity, Smarty十分相似。

  • 对于大量的硬编码的字符串连接和主流的DOM/DHTML处理来说,JST是一个更容易阅读的替代方案。

借助JavaScript Templates来创建你自己的rich web application(像GMail/OddPost/Bloglines)。

更多信息:

JST 10 分钟简介

首先,在我们的HTML页面中,我们载入TrimPath JST组件到浏览器中

接下来,建立一些结构化JavaScript数据——仅仅是一些对象和数据

下面,这是一个JST模版的例子,它可以指导如何“渲染”数据。我们把我们的JST模版放到HTML页面的隐藏的<textarea>标签中:

这里是显示如何利用 API进行模版处理的代码

返回的结果是:

除了可以从 <textarea>元素中获取我们的模版之外,我们也可以从JavaScript的字符串中获取:

你也许想立即看看这个,JST demo page.


我应该把JST的模版放在哪里?

在上面的介绍中,我们把我们JST模版放在了HTML页面的隐藏的<textarea>标签中。

  • 当然,你可以在一个页面中有多个 <textarea> 元素,来保存不同的JST模版。

    • 一般的语法是:<textarea id="my_template_jst" style="display:none;"> ... 模版内容 ... </textarea>

    • 把JST的<textarea>放入<form>中必须要谨慎,除非你想在点击提交时把他们发送到服务器。

  • 为何使用 <textarea>?

    • <textarea> 元素有一个很好的特性是不会把它内部的代码innerHTML的格式搞乱。

      • <textarea>的innerHTML的稳定性十分重要因为JST语法允许在任何奇怪的位置放入一些控制流标记(如 if/elseif/for),甚至在HTML标签中,例如:

        • <option value="${country.name}" {if country.name == currCountry}selected{/if}>

      • 就和大多数服务器端模版语言一样,JST的语法并不是真正的HTML/XHTML/XML。因此,使用<textarea>来存放JST模版是最好的。

    • 关于<textarea>要注意: 浏览器会转化<textarea>的内容中的 < 和 > 变成 &lt; 和 &gt;。

      • 所以,TrimPath.parseDOMTemplate() 和 TrimPath.processDOMTemplate() 会自动把 < 和 > 转化回来,这样你仍然可以使用这个模版。

还有,你也可以把 *.jst 文件放在Web服务器上,并且通过XMLHttpRequest 或者是隐藏的iframe把他们载入到浏览器中。

服务器端 JST 执行

我们设计JST时不仅让她可以在浏览器中运行同时还可以在任何单独的JavaScript解释器中运行(例如 Mozilla Rhino 或者是 SpiderMonkey)。核心的 JST 引擎不会依赖关键的DOM/DHTML/浏览器。

PHP 对比 PERL

本文是 http://tnx.nl/php – 如果你要复制他,请保持这个链接。

翻译:ShiningRay @Nirvana Studio

目录

参数和返回值极其矛盾

要展示这个问题,下面有一个函数列表,里面的函数用来匹配用户定义的内容:(也许甚至那些用PHP的人才会使用这个文档,只是用来查看该用哪个函数:P)

  匹配 替换使用 大小写敏感 返回的数字 数组参数 返回匹配 s/m/x标志 偏移(-1=结尾)
ereg ereg   所有 数组 0
ereg_replace ereg 字符串 所有 0
eregi ereg   所有 数组 0
eregi_replace ereg 字符串 所有 0
mb_ereg ereg[1]   所有 数组 0
mb_ereg_replace ereg[1] 字符串/表达式 所有 0
mb_eregi ereg[1]   所有 数组 0
mb_eregi_replace ereg[1] 字符串 所有 0
preg_match preg[2]   皆可 一个 数组 0
preg_match_all preg   皆可 所有 数组 0
preg_replace preg 字符串/表达式 皆可 无/所有 0
str_replace str 字符串 所有 数字 0
str_ireplace str 字符串 所有 数字 0
strstr, strchr str   一个 子串 0
stristr str   一个 子串 0
strrchr str   一个 子串 -1
strpos str   一个 索引 n
stripos str   一个 索引 n
strrpos char[3]   一个 索引 n
strripos str   一个 索引 -1
mb_strpos str[1]   一个 索引 n
mb_strrpos str[1]   一个 索引 -1

这种问题还存在在其他的函数组里,不仅仅是匹配的这部分而已。

(在Perl中,所有这些功能都可以通过四个简单的操作符来完成。)

[1] 用于处理多字节字符
[2] PCRE regex: 所谓的“Perl兼容”的正则表达式。
[3] 在PHP5中也是字符串str

PHP对大小写不敏感的操作使用不同的函数

(这个可能会有两方面的争论。有些人认为提供不同的函数更好,即使这意味着又要记很多名词了)

在Perl中,你可以使用两个lc() 或者是 /i 标志,而PHP通常会提供一个大小写敏感的变量。而且,大小写不敏感的那些版本的函数名的命名方式也不一致。

Perl: $foo cmp $bar lc $foo cmp lc $bar
PHP: strcmp($foo, $bar) strcasecmp($foo, $bar)
     
Perl: index($foo, $bar) index(lc $foo, lc $bar)
PHP: strpos($foo, $bar) stripos($foo, $bar)
     
Perl: $foo =~ s/foo/bar/ $foo =~ s/foo/bar/i
PHP: $foo = str_replace('foo', 'bar', $foo) $foo = str_ireplace(...)
PHP: $foo = ereg_replace('foo', 'bar' ,$foo) $foo = eregi_replace(...)

PHP的函数命名方式的不一致

  • 大小写不敏感的函数有一个’i’或者’case’在函数名的不同的位置。
  • 毫无表现上的规律 有下划线的 和 没下划线的:
    Perl的核心函数名则没有含有下划线的。
  • PHP 有 unlink 、link 和 rename 和系统调用一致,但是 touch 的系统调用是 utime, 不是 touch。
  • 同时你也无法确定单词的顺序:
    • 宾语 动词:base64_decode, iptcparse, str_shuffle, var_dump
    • 动词 宾语:create_function, recode_string

    Perl的核心函数都是“动词 宾语”结构的除了替代的 dbm* 函数。(注意里面的 sys 是一个前缀,而不是一个宾语。同时 flock 和 lstat
    是根据系统调用命名的。shm* 和 msg* 是库函数调用)

  • “to” 还是 “2”?

    ascii2ebcdic, bin2hex, deg2rad, ip2long, cal_to_jd (jdto*, *tojd), strtolower,
    strtotime,

PHP没有词法范围

Perl 有词法范围和动态范围。PHP则没有。

对于为什么词法范围很重要的解释,可以参考 Coping with Scoping.

  PHP Perl
超全局(Superglobal) [1]
全局(global)
函数局部
词法域(块局部)
动态域

[1] Perl有一些变量总是在main:: 命名空间中。这些类似于PHP的超全局变量。
[2] 在子过程的块中使用一个词法变量,就可以作为一个函数的局部变量。

PHP的主名空间中函数太多

(使用编译了所有核心分发包中的可用扩展的核心库,我们使用了2003年11月发布的版本)

注意,Perl的一些函数有简短的等价语法:

[1] 来源:PHP Quick Reference
[2] 来源:perldoc perlfunc

PHP缺少抽象令 TIMTOWTDI* 走向糟糕的极端

*(There Is More Than One Way To Do It,有不止一种方式来完成它)

为什么PHP有3079个函数但是Perl却只有206个?在PHP中,常常有好几个十分相似的函数。在Perl中,你要了解和记住的要少很多。

另外一个重要的因素是模块的使用,尤其是DBI模块——它用来提供数据库支持,而不是把很多特性塞进内核,占用了空间却很少用到。

(不常用的模块不计算在内(所以这里排除了PHP的PEAR和Perl的IO::File)). 如果核心没有提供类似的功能,那么这些模块也会算在里面。为了简便起见,内部的工作方式将会忽略。)

[1] 因为系统的LIST语法和DBI的占位符,显式转义常常是不需要的。
[2] 在Perl中是由PerlIO层来处理的。

  • Re^2: Is Perl a good career move? by Juerd, 2005
    • 依然没有命名空间
    • 没有闭包,甚至没有匿名函数
    • 没有良好的HTML分析器
    • 没有简单的MIME构建工具
    • 没有良好的WWW库
    • 没有 CPAN
    • 没有数组
    • 没什么用的逻辑操作符
  • Yaywoo! by Dave Brown, 2004
    • 使用system()无法避免(不安全的)shell
    • XY-problem
    • 大量的不同程序,但是,很多只是做了差不多的事情的变体
    • 第二参数和返回值毫无意义
    • 函数名的差劲拼写方式
  • Why PHP sucks by Edwin Martin, 2004,中文翻译 为什么PHP令人不爽(对于大型系统)
    • 不良的递归支持
    • PHP 不是线程安全的
    • PHP 由于商业原因而不健全
    • 没有命名空间
    • 非标准的日期格式化字符
    • 混乱的许可证
    • 不一致的函数命名规则
    • 魔法引用地狱
  • Perl vs. PHP – octo’s subjektiver Vergleich by Florian Forster, 2003 (German)
    • Perl 比 PHP 快很多
    • Perl 比 PHP 更丰富
    • Perl 比 PHP 有更好的文档
    • PHP 缺乏模块化支持
    • PHP的here-docs对Windows用户毫无用途
    • PHP 缺少一致的数据库API
    • PHP 缓存数据库查询结果很危险
    • 图形上,PHP实际上被限制在了 GD 中
  • I hate PHP by Keith Devens, 2003
    • 白痴似的——调用时不推荐引用传递
  • Experiences of Using PHP in Large Websites by Aaron Crane, 2002
    • PHP 是推荐把表现和业务逻辑结合起来的
    • 没有命名空间造成很多问题
    • php.ini 的全局配置
    • 过分简单化导致了额外的复杂度
  • PHP Annoyances by Neil de Carteret, 2002
    • 没有真正的引用或者指针
    • 毫无命名空间的概念
    • 毫不组件化
    • 想变成Perl,但事实上也没想变成Perl
    • 没有标准的DB接口
    • 所有的PHP社区都是针对非程序员的
    • 不支持链式方法调用 (现在已经不是了 –tnx.nl)
    • 没有全局变量除非通过导入
    • register_globals 和 $_REQUEST 都让人痛心
    • 数组都是哈西表
    • PEAR 并不是 CPAN
    • Arrays 不能内插值替换成字符串(如$a=array();$b="$a";是错误的)
    • 没有类似 “use strict” 用来检验变量名的功能
  • PHP: A love and hate relationship by Ivan Ristic, 2002
    • 社区令我不安
    • 知识渊博的人少之又少
    • Zend 发布的文章还建议不安全的实践方式
  • My list of PHP shortcomings by Nathan Torkington, 2001
    • 没有命名空间
    • 所有的函数都是全局的
    • 没有真正的引用
    • 没有真实的数据结构 (现在已经不是了 –tnx.nl)
    • 没有匿名函数

参考

EFnet #php:
19:45 <+Dragnslcr> Comparing PHP to Perl is like comparing pears to newspapers

Perl Monks: PHP – it’s “training wheels without the bike” — Randal L. Schwartz

为什么PHP令人不爽(对于大型系统)

译者:本文其实非常老,大约是2002年的文章,主要针对的是PHP4的版本,其实文中很多问题都随着PHP的不断发展而解决了。有批评才有进步嘛。

Edwin Martin <edwin@bitstorm.org>.

翻译:ShiningRay @ Nirvana Studio

我在过去的四年里一直致力于PHP应用的开发。PHP确实十分容易编写。但是PHP也有一些十分严重的缺陷。

下面我会给出我的理由,为什么PHP不适合于比小型业余网站更大的网站。

1. 对递归的不良支持

递归是一种函数调用自身的机制。这是一种强大的特性可以把某些复杂的东西变得很简单。有一个使用递归的例子是快速排序(quicksort)。不幸的是,PHP并不擅长递归。Zeev,一个PHP开发人员,说道:“PHP
4.0(Zend)对密集数据使用了栈方式,而不是使用堆方式。也就是说它能容忍的递归函数的数量限制和其他语言比起来明显少。”见bug
1901
。这是一个很不好的借口。每一个编程语言都应该提供良好的递归支持。

2. 许多PHP模块都不是线程安全的

在几年前,Apache发布了Web服务器的2.0版。这个版本支持多线程模式,在这个模式下,软件一个一部分可以同时运行多个。PHP的发明者说PHP的核心是线程安全的,但是非核心模块不一定是。但是十次有九次,你想要在PHP脚本中使用这种模块,但这又使你的脚本不能合适Apache的多线程模式。这也是为什么PHP小组不推荐在Apache
2 的多线程模式下运行PHP
。不良的多线程模式支持使PHP常被认为是Apache 2依然不流行的原因之一。

请阅读这篇讨论: Slashdot: Sites Rejecting Apache 2?.

3. PHP 由于商业原因而不健全

通过使用缓存,PHP的性能可以陡增500%[见基准测试]。那么为什么缓存没有被构建在PHP中呢?因为Zend——PHP的制造者,它在销售自己的Zend
Accelerator
,所以当然,他们不想抛弃自己的商业产品这块肥肉。

但是有另一个可选择的: APC.
(Zend后来推出Zend Optimizer,免费的加速器——译者)

4. 没有命名空间

设想某个人制作了一个PHP模块用来阅读文件。模块中一个函数叫做read。然后另一个人的模块可以读取网页的,同样包含一个函数read。然后我们就无法同时使用这两个模块了,因为PHP不知道你要用哪个函数。

但是有一个很简单的解决方法,那就是命名空间。曾经有人建议PHP5加入这个特性,但不幸得是他没有这么做。现在,没有命名空间,每个函数都必须加上模块名作为前缀,来避免名称冲突。这导致了函数名恐怖得长,例如xsl_xsltprocessor_transform_to_xml让代码难于书写和理解。

5. 不标准的日期格式字符

很多程序员对 日期格式字符
都很熟悉,它是从UNIX和C语言中来的。其他一些编程语言采用了这个标准,但是很奇怪的,PHP有它自己的一套完全不兼容的日期格式字符。在C中,“%j”表示一年中的当天,在PHP中他表示一个月中的当天。然而使事情更混乱的是:Smarty
(一个很流行的PHP模版引擎)的 strftime
函数和 date_format
函数,却使用了C/UNIX的格式化字符。

6. 混乱的许可证

你也许认为PHP是免费的,所有的在手册中提到的PHP模块也是免费的。错了!例如,如果你想在PHP中生成PDF文件,你会在手册中发现两个模块:PDF
ClibPDF。但是这两个都是有商业许可证的。所以,你所使用的每个模块,你都要确保你同意他的许可证。

7. 不一致的函数命名规则

有些函数名称是有多个单词组成的。一般有三种单词组合的习惯:

  1. 直接拼接:getnumberoffiles
  2. 用下划线分开:get_number_of_files
  3. 骆驼法则:getNumberOfFiles

大部分语言选择其中一中。但是PHP都用到了。

例如,你想要把一些特殊字符转换成HTML实体,你会使用函数htmlentities
(直接拼接单词)。如果你要使用相反的功能,你要用到它的小弟弟html_entity_decode。由于某些特殊的原因,这个函数名是由下划线分隔单词。怎么能这样呢?你知道有一个函数叫strpad。或者他是str_pad?每次你都要查看一下到底这个符号是什么或者直接等他出现一个错误。函数是不分大小写的,所以对于PHP来说rawurldecode
RawUrlDecode之间没有什么区别。这也很糟糕,因为两个都使用到了同时他们看上去还不一样,混淆了阅读者。

8. 魔法引用的地狱

魔法引用(Magic quote)可以保护PHP脚本免受SQL注入攻击。这很好。但是出于某些原因,你可以在php.ini中关闭这个配置。所以你如果要写出一个有弹性的脚本,你总要检查魔法引用是开启还是关闭。这样一个“特性”应该让编程更简单,而事实上变得更复杂了。

9. 缺少标准框架

一个成长中的网站没有一个整体框架,最终会变成维护的噩梦。一个框架可以让很多工作变得简单。现在最流行的框架模型时MVC-模型,在其中表现层、业务逻辑和数据库访问都分离开了。

很多PHP网站不使用MVC-模型。他们甚至没有一个框架。甚至现在有一些PHP框架同时你都可以自己写一个,关于PHP的文章和手册没有提高框架的一个字。同时JSP-开发人员使用像Struts的框架、ASP开发人员使用.Net,看起来好像这些概念都广泛被PHP开发人员所了解。这就说明了PHP实际上到底是多专业。

总结

超载的汽车什么问题?

对于非常小的项目,它可以是一个十分符合人意的编程语言。但是对于较大的和更为复杂的项目,PHP就显出他的薄弱了。当你不断地摸索之后,你会发现我提到的某些问题的解决方案。所以,当解决方案已知之后,为什么不能修正他呢?另外为什么这些修补不在手册中提到呢?

一个开源的语言十分流行是一件好事。但不幸得是,它不是一个伟大的语言。我希望所有的问题能有一天得到解决(也许在PHP6?),然后我们就将拥有一个开源语言,他既开源,又好用。

到现在,当你要启动一个多于5个脚本页面的项目的时候,你最好考虑C#/ASP.Net 或者 Java/JSP或者也许Python同样是一个更好的选择。

在我写了这篇文章之后,一些人告诉我一些其他的类似文章:

Cake 指南:建立一个简单的Blog

注意!
本指南针对cake_0.9.1_dev 发布版不是SVN的版本。请不要把指南的代码改成于SVN一样。

Cake 指南:建立一个简单的Blog

这是一个还在不断变化的一个应用框架的指南。文章中的东西可能可以运行,但是如果有些东西无法运行,请您先仔细阅读 API 文档 。错误报告对我们很有价值,所以,请报告任何影响您使用的地方。

注意:命名方法的约定已经从下划线_风格变成了骆驼回归法则。所以,在我们目前的发布版中link_to()已经变成linkTo()

默认Cake目录结构一览

在本篇指南中,我们将一起使用Cake来创建一个简单的Blog应用。我假设你对PHP十分了解,可以在你的系统中游刃有余(包括从命令行中运行程序),同时已经有一个配置好的开发服务器环境,例如运行PHP的 XAMPP

下载

下载最新的Cake 包并解压缩到你的Web服务器的DOCUMENT_ROOT下(因为本文是指南的缘故,我假设他可以从http://localhost/cake/下访问)。你可以看到基本的目录结构。

创建数据库

创建一个用来存放Blog帖子的表格,并且初始化一些数据。以下是SQL语句:

注意表名称是复数形式, 这是Cake使用的所有表格的默认形式。还有,idcreatedupdated字段是有特殊含义的,等一会儿你就会发现。也就是说现在你不应该更改他们的名字

配置Cake的数据库设置

若要配置数据库访问,我们编辑 config/database.php.default (他应该是自己包含说明的), 并将它保存为config/database.php. 如果 config/database.php 不存在,Cake仍会运行,并且不使用数据库访问。

创建一个模型类 (MVC中的Model)

现在给帖子表格posts创建一个模型类,新建 app/models/post.php包含以下内容 :

app/models/post.php

这已经足以使Cake来关注这个模型了,载入、并把它和数据库表格连接在一起。注意:模型类的类名是单数形式。坚持命名约定十分重要,因为如果不这样,Cake就不会自动运行。默认情况下,模型类和数据库表使用同一个单词而前者以单数形式,后者是复数形式。

建立一个控制器助手类

新建一个控制器助手类。把下面的内容放在 app/helpers/posts_helper.php中:

app/helpers/posts_helper.php

创建一个控制器类 (C ontroller)

新建一个控制器类. 把下面的内容放在 app/controllers/posts_controller.php中:

app/controllers/posts_controller.php

控制器已经准备好了,这是我们需要在他里面添上行为(Action)来对存储的数据进行操作。添加一个方法到 PostsController 类中 :

app/controllers/posts_controller.php

PostsController::index() 不需要其他内容了,除了需要一个模版(在Cake中称之为视图“View”)。

建立一个视图 (View)

把下面的代码放入 app/views/posts/index.thtml:

这应该可以正确运行,我们来测试一下。我假设你可以通过浏览 http://localhost/cake/ 来得到Cake目录,这样测试一下我们的新控制器,它指向 http://localhost/cake/posts/index 。你会(希望如此)看到类似于下面的一些东西:

为什么我没看到呢?

如果你遇到了一个页面,上面说“not Found: The requested URL /posts/index was not found on this server,”你可能要使用 http://localhost/cake/index.php?url=posts来访问. 很明显,这很不美观。如果你遇到了一个页面上说“Fatal error: Call to a member function on a non-object …”那么你可能要检查一下你的配置内容,有没有把config/database.php.default 改名为 config/database.php. 参见 Blog指南中的故障及解决方法

我们现在做了些什么?

让我们回顾一下。我们创建了数据库表posts,一个模型类Post,一个控制器PostsController 和他的 index()方法,还有一个视图文件app/views/posts/index.thtml。我觉得他一点也不困难。让我们继续吧。

帖子标题是连接到/cake/posts/view/[post_id]的. 让我们点击它。

噢~,对了,我们忘记添加PostsController::view()行为了。让我们现在完成它:

app/controllers/posts_controller.php

还有视图文件:

app/views/posts/view.thtml

回到浏览器,刷新,看到:

成功了!

添加功能

在指南的第一部分之后,我们有了一个帖子的列表,同时我们可以查看帖子了。当我们完成了第二部分,我们可以:

  • 添加一个新的帖子。
  • 删除不要的帖子。
  • 编辑存在的帖子。

添加一个新的帖子

添加一个新的帖子:

app/controllers/posts_controller.php

同时行为的模版文件是:

app/views/posts/add.thtml

现在你可以通过地址”/cake/posts/add”来访问 add 页面 page at the address “/cake/posts/add”, 或者,我们可以在索引页面的底部放上一个快捷的 “Add new post”连接:

app/views/posts/index.thtml

现在让我们试试添加一些帖子。

像我这样没规矩的,添加了一个没有标题的帖子。当然,我们可以通过数据有效性检验(Data Validation)来避免这种不正确的行为。

数据有效性

数据有效性规则是放在数据模型中的。

app/models/post.php

了解API文档中更多关于有效检验器的内容。

删除一个帖子

app/controllers/posts_controller.php

delete 行为没有模版。在成功删除之后,我们只要显示一个快捷消息(所谓的“flash”),然后转回索引页面。

现在我们添加一个删除行为的连接到每一个blog帖子的视图中:

app/views/posts/index.thtml

在完成它之后,我们就可以删除那些空白标题的帖子了。

编辑帖子

app/controllers/posts_controller.php

app/views/posts/edit.thtml

你也可以在表单标签中用

来代替直接使用html的<input>标签。

同时, 在 index.thtml 中, 我们添加一个编辑连接:

从视图中分离逻辑

让我们回头看一下 index.thtml 视图:

app/views/posts/index.thtml

我们应该从视图中删除 findAll() 的调用,然后把它放在控制器重。这可以建立一种更好的逻辑和视图的分离。然后我们从控制器重为视图获取数据。现在就让我们完成它吧。

在帖子的控制器中,我们从posts模型中获取所有的记录,并且储存在变量 data 中。

app/controllers/posts_controller.php

同时在视图中,我们通过对每行数据的迭代,来全部显示他的内容。

app/views/posts/index.thtml

这太简单了,不是么?

在数据库中存储层次数据

在数据库中存储层次数据

作者:Gijs Van Tulder
翻译:ShiningRay @ NirvanaStudio

无论你要构建自己的论坛,在你的网站上发布消息还是书写自己的cms [1]程序,你都会遇到要在数据库中存储层次数据的情况。同时,除非你使用一种像XML [2]的数据库,否则关系数据库中的表都不是层次结构的,他们只是一个平坦的列表。所以你必须找到一种把层次数据库转化的方法。

存储树形结构是一个很常见的问题,他有好几种解决方案。主要有两种方法:邻接列表模型和改进前序遍历树算法

在本文中,我们将探讨这两种保存层次数据的方法。我将举一个在线食品店树形图的例子。这个食品店通过类别、颜色和品种来组织食品。树形图如下:

1105_tree

本文包含了一些代码的例子来演示如何保存和获取数据。我选择PHP [3]来写例子,因为我常用这个语言,而且很多人也都使用或者知道这个语言。你可以很方便地把它们翻译成你自己用的语言。

邻接列表模型(The Adjacency List Model)

我们要尝试的第一个——也是最优美的——方法称为“邻接列表模型”或称为“递归方法”。它是一个很优雅的方法因为你只需要一个简单的方法来在你的树中进行迭代。在我们的食品店中,邻接列表的表格如下:

1105_table1

如你所见,对每个节点保存一个“父”节点。我们可以看到“Pear [4]”是“Green”的一个子节点,而后者又是“Fruit”的子节点,如此类推。根节点,“Food”,则他的父节点没有值。为了简单,我只用了“title”值来标识每个节点。当然,在实际的数据库中,你要使用数字的ID。

显示树

现在我们已经把树放入数据库中了,得写一个显示函数了。这个函数将从根节点开始——没有父节点的节点——同时要显示这个节点所有的子节点。对于这些子节点,函数也要获取并显示这个子节点的子节点。然后,对于他们的子节点,函数还要再显示所有的子节点,然后依次类推。

也许你已经注意到了,这种函数的描述,有一种普遍的模式。我们可以简单地只写一个函数,用来获得特定节点的子节点。这个函数然后要对每个子节点调用自身来再次显示他们的子节点。这就是“递归”机制,因此称这种方法叫“递归方法”。

要实现整个树,我们只要调用函数时用一个空字符串作为$parent$level = 0: display_children('',0); 函数返回了我们的食品店的树状图如下:

注意如果你只想看一个子树,你可以告诉函数从另一个节点开始。例如,要显示“Fruit”子树,你只要display_children('Fruit',0);

节点的路径

利用差不多的函数,我们也可以查询某个节点的路径如果你只知道这个节点的名字或者ID。例如,“Cherry”的路径是“Food”>“Fruit”>“Red”。要获得这个路径,我们的函数要获得这个路径,这个函数必须从最深的层次开始:“Cheery”。但后查找这个节点的父节点,并添加到路径中。在我们的例子中,这个父节点是“Red”。如果我们知道“Red”是“Cherry”的父节点。

这个函数现在返回了指定节点的路径。他把路径作为数组返回,这样我们可以使用print_r(get_path('Cherry')); 来显示,其结果是:

不足

正如我们所见,这确实是一个很好的方法。他很容易理解,同时代码也很简单。但是邻接列表模型的缺点在哪里呢?在大多数编程语言中,他运行很慢,效率很差。这主要是“递归”造成的。我们每次查询节点都要访问数据库。

每次数据库查询都要花费一些时间,这让函数处理庞大的树时会十分慢。

造成这个函数不是太快的第二个原因可能是你使用的语言。不像Lisp这类语言,大多数语言不是针对递归函数设计的。对于每个节点,函数都要调用他自己,产生新的实例。这样,对于一个4层的树,你可能同时要运行4个函数副本。对于每个函数都要占用一块内存并且需要一定的时间初始化,这样处理大树时递归就很慢了。

改进前序遍历树

现在,让我们看另一种存储树的方法。递归可能会很慢,所以我们就尽量不使用递归函数。我们也想尽量减少数据库查询的次数。最好是每次只需要查询一次。

我们先把树按照水平方式摆开。从根节点开始(“Food”),然后他的左边写上1。然后按照树的顺序(从上到下)给“Fruit”的左边写上2。这样,你沿着树的边界走啊走(这就是“遍历”),然后同时在每个节点的左边和右边写上数字。最后,我们回到了根节点“Food”在右边写上18。下面是标上了数字的树,同时把遍历的顺序用箭头标出来了。

1105_numbering

我们称这些数字为左值和右值(如,“Food”的左值是1,右值是18)。正如你所见,这些数字按时了每个节点之间的关系。因为“Red”有3和6两个值,所以,它是有拥有1-18值的“Food”节点的后续。同样的,我们可以推断所有左值大于2并且右值小于11的节点,都是有2-11的“Food”节点的后续。这样,树的结构就通过左值和右值储存下来了。这种数遍整棵树算节点的方法叫做“改进前序遍历树”算法。

在继续前,我们先看看我们的表格里的这些值:

1105_table2

注意单词“left”和“right”在SQL中有特殊的含义。因此,我们只能用“lft”和“rgt”来表示这两个列。(译注——其实Mysql中可以用“”来表示,如“left`”,MSSQL中可以用“[]”括出,如“[left]”,这样就不会和关键词冲突了。)同样注意这里我们已经不需要“parent”列了。我们只需要使用lft和rgt就可以存储树的结构。

获取树

如果你要通过左值和右值来显示这个树的话,你要首先标识出你要获取的那些节点。例如,如果你想获得“Fruit”子树,你要选择那些左值在2到11的节点。用SQL语句表达:

这个会返回:

1105_table3

好吧,现在整个树都在一个查询中了。现在就要像前面的递归函数那样显示这个树,我们要加入一个ORDER BY子句在这个查询中。如果你从表中添加和删除行,你的表可能就顺序不对了,我们因此需要按照他们的左值来进行排序。

就只剩下缩进的问题了。

要显示树状结构,子节点应该比他们的父节点稍微缩进一些。我们可以通过保存一个右值的一个栈。每次你从一个节点的子节点开始时,你把这个节点的右值添加到栈中。你也知道子节点的右值都比父节点的右值小,这样通过比较当前节点和栈中的前一个节点的右值,你可以判断你是不是在显示这个父节点的子节点。当你显示完这个节点,你就要把他的右值从栈中删除。要获得当前节点的层数,只要数一下栈中的元素。

如果运行这段代码,你可以获得和上一部分讨论的递归函数一样的结果。而这个函数可能会更快一点:他不采用递归而且只是用了两个查询

节点的路径

有了新的算法,我们还要另找一种新的方法来获得指定节点的路径。这样,我们就需要这个节点的祖先的一个列表。

由于新的表结构,这不需要花太多功夫。你可以看一下,例如,4-5的“Cherry”节点,你会发现祖先的左值都小于4,同时右值都大于5。这样,我们就可以使用下面这个查询:

注意,就像前面的查询一样,我们必须使用一个ORDER BY子句来对节点排序。这个查询将返回:

我们现在只要把各行连起来,就可以得到“Cherry”的路径了。

有多少个后续节点?How Many Descendants

如果你给我一个节点的左值和右值,我就可以告诉你他有多少个后续节点,只要利用一点点数学知识。

因为每个后续节点依次会对这个节点的右值增加2,所以后续节点的数量可以这样计算:

利用这个简单的公式,我可以立刻告诉你2-11的“Fruit”节点有4个后续节点,8-9的“Banana”节点只是1个子节点,而不是父节点。

自动化树遍历

现在你对这个表做一些事情,我们应该学习如何自动的建立表了。这是一个不错的练习,首先用一个小的树,我们也需要一个脚本来帮我们完成对节点的计数。

让我们先写一个脚本用来把一个邻接列表转换成前序遍历树表格。

这是一个递归函数。你要从rebuild_tree('Food',1); 开始,这个函数就会获取所有的“Food”节点的子节点。

如果没有子节点,他就直接设置它的左值和右值。左值已经给出了,1,右值则是左值加1。如果有子节点,函数重复并且返回最后一个右值。这个右值用来作为“Food”的右值。

递归让这个函数有点复杂难于理解。然而,这个函数确实得到了同样的结果。他沿着树走,添加每一个他看见的节点。你运行了这个函数之后,你会发现左值和右值和预期的是一样的(一个快速检验的方法:根节点的右值应该是节点数量的两倍)。

添加一个节点

我们如何给这棵树添加一个节点?有两种方式:在表中保留“parent”列并且重新运行rebuild_tree()
函数——一个很简单但却不是很优雅的函数;或者你可以更新所有新节点右边的节点的左值和右值。

第一个想法比较简单。你使用邻接列表方法来更新,同时使用改进前序遍历树来查询。如果你想添加一个新的节点,你只需要把节点插入表格,并且设置好parent列。然后,你只需要重新运行rebuild_tree() 函数。这做起来很简单,但是对大的树效率不高。

第二种添加和删除节点的方法是更新新节点右边的所有节点。让我们看一下例子。我们要添加一种新的水果——“Strawberry”,作为“Red”的最后一个子节点。首先,我们要腾出一个空间。“Red”的右值要从6变成8,7-10的“Yellow”节点要变成9-12,如此类推。更新“Red”节点意味着我们要把所有左值和右值大于5的节点加上2。

我们用一下查询:

现在我们可以添加一个新的节点“Strawberry”来填补这个新的空间。这个节点左值为6右值为7。

如果我们运行display_tree() 函数,我们将发现我们新的“Strawberry”节点已经成功地插入了树中:

缺点

首先,改进前序遍历树算法看上去很难理解。它当然没有邻接列表方法简单。然而,一旦你习惯了左值和右值这两个属性,他就会变得清晰起来,你可以用这个技术来完成临街列表能完成的所有事情,同时改进前序遍历树算法更快。当然,更新树需要很多查询,要慢一点,但是取得节点却可以只用一个查询。

总结

你现在已经对两种在数据库存储树方式熟悉了吧。虽然在我这儿改进前序遍历树算法性能更好,但是也许在你特殊的情况下邻接列表方法可能表现更好一些。这个就留给你自己决定了

最后一点:就像我已经说得我部推荐你使用节点的标题来引用这个节点。你应该遵循数据库标准化的基本规则。我没有使用数字标识是因为用了之后例子就比较难读。

进一步阅读

数据库指导 Joe Celko写的更多关于SQL数据库中的树的问题:
http://searchdatabase.techtarget.com/tip/1,289483,sid13_gci537290,00.html [6]

另外两种处理层次数据的方法:
http://www.evolt.org/article/Four_ways_to_work_with_hierarchical_data/17/4047/index.html [7]

Xindice, “本地XML数据库”:
http://xml.apache.org/xindice/ [8]

递归的一个解释:
http://www.strath.ac.uk/IT/Docs/Ccourse/subsection3_9_5.html [9]

[1] http://www.sitepoint.com/glossary.php?q=C#term_28
[2] http://www.sitepoint.com/glossary.php?q=X#term_3
[3] http://www.sitepoint.com/glossary.php?q=P#term_1
[4] http://www.sitepoint.com/glossary.php?q=P#term_50
[5] http://www.sitepoint.com/glossary.php?q=%23#term_72
[6] http://searchdatabase.techtarget.com/tip/1,289483,sid13_gci537290,00.html
[7] http://www.evolt.org/article/Four_ways_to_work_with_hierarchical_data/17/4047/index.html
[8] http://xml.apache.org/xindice/
[9] http://www.strath.ac.uk/IT/Docs/Ccourse/subsection3_9_5.html

PEAR DB_Table 简介

翻译:ShiningRay @ NirvanaStudio

原文地址:http://wiki.ciaweb.net/yawiki/index.php?area=DB_Table

什么是 DB_Table?

DB_Table 是一个用于访问数据库表的面向对象接口。作为一个PEAR DB类的一个 包装,它提供了一些帮助你构建自动的创建、插入、更新和选择功能的方法。同时还有利用 HTML_QuickForm 自动构建输入表单的方法。

DB_Table提供了什么?

DB_Table 提供了:

  • 一个嵌在类属性中的模式描述系统,包括:
    • 列定义
    • 索引定义
    • 标准查询
    • 创建HTML_QuickForm元素的属性
  • 从描述的模式自动创建表
  • 一个抽象的API这样即便你改变了数据库后台也不需要改变你的PHP调用。这套API扩展了PEAR DB的功能,同时包含:
    • 用于根据预定义的SQL查询来获取一个结果数组的select() 方法
    • 用于根据预定义的SQL查询来获取一个PEAR DB_Result 对象的selectResult() 方法
    • create(), insert(), update(), 和 delete() 方法
    • 自动模式检验
    • 根据描述的表模式进行插入和更新字段时的自动检验
  • 时间和日期数据类型抽象,覆盖了数据库的原始数据类型
    • 即使你更改了数据库的后端,也无需修改你的查询。
    • 不需要通过类型转换方法来改变查询的值。
    • 当你插入或者更新列时,DB_Table 根据DB_Table 数据类型自动检验数据(datatype automatically (对所有的数据类型: integer, string,等等.).
  • 根据描述的模式自动创建HTML_QuickForm元素,利用以下方法:
    • getForm() 获取整个表单对象,有HTML_QuickForm元素和规则。
    • getFormGroup() 获取一组HTML_QuickForm元素。
    • getFormElement() 获取单一的HTML_QuickForm元素
    • addFormElements?() 对一个存在的HTML_QuickForm元素添加一个表单元素。
  • DB_Table 支持以下数据库(通过PEAR DB):
    • FrontBase
    • Microsoft SQL
    • MySQL
    • Oracle 8i
    • PostgreSQL
    • SQLite

类似的项目

PEAR MDBMDB2 提供真正的日期和时间数据类型的抽象,以及根据XML定义模式新建表的功能,但是它缺乏自动查询定义也不支持快速生成表单。同时,即使你在XML文件中定义了你的模式,每次进行查询的时候你还是要手工通知MDB/MDB2你的列类型是什么。

Metabase (by Manuel Lemos) 是PEAR MDB的祖先, Manuel也写了 Metastorage

PEAR DB_DataObject 是一个完整的数据对象封装器,支持完整的模式和连接表格,可以在一个外部的.ini文件中描述。

Propel 是“一个为PHP5设计的全服务对象持久和查询工具”。他的意思,用实际的语言说,就是Propel可以让你把你的数据库当成一系列的对象,提供了一套简便的API来存储和查询数据。其他与这类工具相关的名词有:对象关系映射(Object Relational Mapping, ORM)和数据访问对象(Data Access Objects,DAO)。Propel提供了一个生成器,用来创建SQL语句和PHP类同时提供了管理对象持久化和取回的运行时环境。

DB_DataContainer 和DB_Table十分相似。从网站上看“DB_DataContainer是一个PEAR兼容的数据库持久层和数据封装类。一个持久层封装了持久化对象所需要的行为,也就是,从一个持久存储器中载入、保存和删除对象,一般来说这个存储器是一个SQL数据库服务器。目前唯一支持的持久机制是关系数据库。数据库抽象由PEAR DB提供。未来将会提供对普通文件的支持。

Python 不是 Java

作者:Phillip J. Eby.

翻译:ShiningRay @ NirvanaStudio

原文地址:http://dirtsimple.org/2004/12/python-is-not-java.html


我最近正在看一个基于wxPython的GUI应用程序,大概45.5KLOC的样子,但我没有计算它用到的库的大小(如Twisted)。代码是由那些对Python相对生疏的Java的开发者写的,所以程序有很严重的性能问题(如三十秒的启动时间)。我在检查代码的时候发现他们写了很多对Java有意义但是对Python却很恐怖的东西。并不是因为“Python比Java慢”,而是因为在Python中有更方便的方法去完成同样的目标,甚至在Java中不可能的事情。

所以,可悲的事就是这些可怜人事倍功半,产生了很多很多不需要写的代码,从而比相应合乎Python习惯的写法慢得多得多。我们来看一些例子:

  • 在Java中一个静态的方法(static)不能翻译成一个Python的类方法(classmethod)。哦,当然,多多少少他最终产生类似的效果,但类方法的目的实际上是做了一些通常在Java中不可能的事(如继承一个非默认的构造函数)。Java静态方法的习惯翻译通常是一个模块级函数,而不是一个类方法或静态方法(staticmethod)。(同时静态封闭(final)字段应该翻译成模块级常量。)

    这并不是一个性能上的问题,但是一个Python程序员要用像这些类似Java习惯的代码的话,可能就会被在该输入Foo.someFunction时却要输入Foo.Foo.someMethod这种情况给惹毛了。但是请注意:调用一个类方法将会比调用一个静态方法和函数要多一部分额外的内存。

    啊,那些Foo.Bar.Baz也不是省油的。在Java中,这些点分割的名称是由编译器去查找的,所以运行时根本无所谓你有多少点。在Python中,每次运行时都要查找,所以每个点都要计算在内。(Python中一定要记住这点,“平铺比嵌套好”,尽管比起性能,他和“可读性”和“简单就是美”更靠近。)

  • 要用switch语句?Python翻译将是一个哈希表,不是一堆if-then语句。用一堆if-then在Java中也不是switch语句,如果有字符串参与了呢?他其实是一个哈希表。CPython字典实现用了性能最佳—在我们宇宙中目前所知道的—的哈希表的实现之一。你自己所写的代码也不会比这个再好了,除非你是Guido、Tim Peters和Raymond Hettinger的“私生子”——还是遗传增强了的。
  • XML不是答案。它也不是一个问题。要在正则表达式上解释Jamie Zawinski,“一些人,当遇到一个问题的时候,就想‘我知道,我要用XML’那这个时候,他们就有两个问题了。”

    和Java比,这是一个不同的情况。因为比起Java代码,XML是轻巧而且有弹性的。但比起Python的代码来,XML就是一个船锚,一个绊脚石。在Python中,XML是用来做交换,而不是你的核心功能,因为你不需要这么做。在Java中,XML可能是你的大救星因为他让你实现了特定领域的语言并“不通过编码”提高了你的应用程序的适应性。在Java中,避免编码是一个很大的优势,因为编码意味着重新编译。但在Python中,更常见的是,写代码比写XML更方便简单。同时Python处理代码要远远比处理XML快。(不仅仅是这个,你必须书XML处理代码,同时Python自身就已经为你准备好了。)

    如果你是一个Java程序员,对于你是否要在你的Python核心应用中使用XML作为一部分,不要相信你的本能。如果你不是因为信息交互的原因去实现一个已经存在的XML标准或是建立某种导入、导出格式或者建立某种XML编辑器或处理工具,那么就不要这么做。一次也别。甚至连想都不要想。现在,扔掉那个XML模式把你的手解放吧!如果你的应用程序或者平台要被Python开发者使用,他们只会感谢你不要在他们的工作量中添加使用XML的负担。

    (这里唯一的例外是如果你的受众的的确确,确确实实需要XML,出于某种奇怪的理由。像,他们拒绝学习Python并只对你使用了XML而付钱给你,或者你打算给他们一个编辑XML的GUI,同时这个写XML的GUI呢是另一个人写的,同时你得到免费使用的权利。还有一些很少见的架构上的原因需要用到XML。相信我,他们不会出现在你的程序中。如果有疑问,对一个资深的Python开发员解释你的用例。或者,如果你脸皮厚的话,试试向一个Lisp程序解释你的程序为什么要用XML!)

  • Getter和setter是坏蛋。坏蛋,魔鬼!Python对象不是Java Bean。不要写什么getter和setter,然后还把它们包装在“属性”里面。它直到你能证明你需要比一个简单访问复杂一点的功能时才有意义,否则,不要写getter和setter。它们是CPU时间的浪费,更要紧的是,它们还是程序员宝贵时间的极大浪费。不仅仅对于写代码和测试的人,对于那些要阅读和理解它们的人也是。

    在Java中,你必须使用getter和setter因为公共字段不允许你以后改变想法再去使用getter和setter。在Python中,这样做很傻,因为你可以以一个普通特性开始并可以在任何时间改变你的想法,而不用影响到这个类的任何客户。所以不要写getter和setter。

  • 代码重复在Java中常常是一个不得不要的魔鬼,你必须经常一遍一遍写同一个方法而只有一点点的变化(通常是因为静态类型约束)。在Python中这样做是没有必要的也是不值得的(除了极少数一些特定的场合需要内联一些要求性能的函数)。如果你发现自己一遍一遍在写同样的代码而且变化很少,你就需要去学一下闭包。他们并不是真的很可怕。

    这就是你要做的。你写了一个包含了函数的函数。这里内部的函数就是你要一遍遍写的函数的模版,但是在里面加入了针对不同情况的函数要使用变量。外部的函数需要刚刚提高的那种变量作为参数,并且将内部的函数作为结果返回。然后,每次你要写另一种略微不同的函数的时候,你只要调用这个外部的函数,并且把返回值赋给你要让“重复”函数出现的名字。现在,如果你需要改变这个工作方式,你只要改变一个地方:这个模版。

在我所看过的应用程序/平台中,只有一个很微不足道的程序使用了这个技术之后可以去掉数百行重复代码。事实上,自从开发者使用了特别的样板文件来为这平台开发插件,这会节省很多很多第三方开发人员的代码,同时也使那些程序员要学习的东西简化了。

这只是Java->Python思维方式转变的冰山一角而已,现在我可以让他转变成正确的而不用钻研这个程序的细节。本质上,如果你曾经用过一段时间Java,而且对Python比较陌生,不要太相信自己的本能。你的本能已经为Java调节,而不是Python。向后退一步,最重要的,不要写这么多代码了。

要这样做,让自己觉得更加需要Python。假装好像Python是可以做任何你想做的魔棒,却让你无须动一个手指。问一下,“Python是怎样解决我的问题的?”还有“Python语言的哪个特点和我的问题最相似?”你绝对会惊讶于你需要的东西其实已经有了某种固定形式。事实上,这种现象实在是太普遍了,甚至在很有经验的Python程序员中也会出现,以至于Python社区中给这种现象起了个名字。我们称之为“GUIDO的时间机器”,因为有时候看上去得到我们所需要的东西好像只有他知道的一种方法,但当我们自己知道了就不一样了。

所以,如果你不能感到你在使用Python时至少比用Java要多出10倍的生产力,!(同时如果你还怀念你的Java IDE,考虑一下这种可能性:因为你写的Python程序比他所需要的要复杂得多)


附录:(翻译自此篇文章的评论)

确实,哈希表==字典。举个最简单的例子,从Python

标准库中检出“pickle”和“copy”模块,这两个模块会从字典中查找类型并调用相应的函数。另一个有些诡异的例子是范型函数,我已经在最近的Blog中写了一下。

关于闭包的例子,我这里给出一个很笨的例子。假设你要写很多这样的函数:

def addOne(x): return x+1
def addTwo(x): return x+2

然后你可以这样写:

def makeAdder(addend):
… def add_it(x): return x+addend
… return add_it

并且这样使用:

addOne = makeAdder(1)
addTwo = makeAdder(2)

这样就可以等同于原来的定义了。

相关资料:http://www.razorvine.net/python/PythonForJavaProgrammers

QBASIC中的活动图像

翻译:ShiningRay