尽管很多人认为,对象是‘穷人’的闭包,但实际上,闭包是‘穷人’的对象。


从一种角度来看,这是事实,当在一种没有闭包功能的语言里使用特殊处理的对象来达到闭包效果时,我就会想到这些。 我们可以把闭包简单的看成一种这样的资源:通过某种方式把自己的各种功能简单参数化的对象或接口。 想在Java或C++里尝试函数式编程的人都会遇到这种情况 – 这样可以实现其功能,但很别扭。 如果你确实要实现一个这样的功能(例如Scheme语言里的map somefun mylist功能),那么,语言里能够用简单的几句话定义出可执行的“对象”(闭包)的特性是十分让人省心的。

但是从另外的一种观点来看,就像Scheme语言里的闭包能够 apply “函数方法” 一样,可以被当作一种低级底层的方法调度机制,因此,闭包可以、而且肯定能够用来实现非常有实际作用的具有多个方法的对象语义。 Oleg Kiselyov 曾发表过一个简短的文章论述这个问题: http://okmij.org/ftp/Scheme/oop-in-fp.txt 。通过这种方式,我们可以认为闭包比对象更富有能力,因为它比那些仅单纯依靠语言提供的方法调度机制语法支持更多的功能。 闭包,看上去就像是一个代码块,但可以用来实现对象,很明显可以得出,对象是穷人的闭包。

但一个Smalltalk语言开发者会说:稍等,既然你不惜麻烦的在你的语言里用闭包实现这个玩意,而这个玩意也很像对象,那为什么不再花点功夫、用点力 去让它们成为能够拥有任意数量的方法的“真正的”对象呢? 由此可以看出闭包只是一种特殊情况下的对象。如果你的语言里只是拥有这些功能有限的闭包,而你又要强制使用其来实现一个对象系统,那很明显,闭包是穷人的 对象了。

正因为这两种对立的关系, 我感觉闭包和对象之争真有点禅的意思。我想借取禅心,将 Norman Adams (“对象是穷人的闭包”这个论断的发明者)和 Christian Queinnec (“闭包是穷人的对象“说法的发明人) 合并成一个叫 Qc Na 的禅宗身上,编出一段故事。而将我自己以一个谦虚的学生的身份插到故事里。 这样做是因为,我在这里 http://www.ai.mit.edu/~gregs/ll1 ... -html/msg01488.html 最后一段也说过这些 …我觉得在考虑这两个显然完全对立的说法时,受到了很多的启发,就像下面说的:

* * *

受人尊敬的大师 Qc Na 和他的学生 Anton 走在一起。为了能和大师发起一次讨论, Anton 说道:“大师,我听说对象是个非常奇妙的东西 – 是真的吗?” 大师不屑的看了他的学生一眼,回答道:“蠢孩子 – 对象仅仅是穷人的闭包。”

被责骂后,Anton 辞别了大师,回到了自己的小房间里,热情的学起闭包知识。 他认真的阅读了所有的”Lambda: … 权威大全”系列文章以及相关资料,而且用Scheme编译器实现了一个小的以闭包为基础的面向对象的语言系统。 他明白了很多事情,急切的想告诉他的老师自己取得的进步。

就在之后的一次跟大师的走路时,Anton 期望让大师对自己留下深刻印象,说到:”大师,我已经认真的学习了那个东西,现在我知道了对象真的是穷人的闭包。“ 大师用手杖打了一顿 Anton, 说道:”你什么时候明白了?闭包是穷人的对象。“

这回,Anton 终于开窍了。



闭包是“穷人”的对象

闭包是“穷人”的对象 What's so cool about Scheme? - 敏捷大拇指 - 闭包是“穷人”的对象




RE: What's so cool about Scheme?

To: "Guy Steele - Sun Microsystems Labs"
Subject: RE: What's so cool about Scheme?
From: "Anton van Straaten" <address@hidden>
Date: Wed, 4 Jun 2003 13:13:21 -0400
In-reply-to: <200306041454.h54EsBh09407@sydney.East.Sun.COM>


Guy Steele wrote:
>    Mike Newhall wrote:
>    At 08:23 PM 2003.06.03 -0400, Anton van Straaten wrote:
>    >I can sort of agree with that, but really, without closures,
>    >people will - and do - use all sorts of hacks anyway -
>    >objects, for example ;o)
>
>            As an aside, although I don't remember the exact argument, Christian
>    Queinnec in LISP In Small Pieces made the case that, although
>    many people consider objects to be 'poor man's closures', closures
>    are in fact poor man's objects (in his opinion).
>
> A closure is an object that supports exactly one method: "apply".


That's true from one perspective, and was what I was thinking of related to
objects being used as hacks to work around lack of closures.  A closure's
simplicity can be an asset: classes and interfaces can get in the way of
simple parameterization of behavior.  Anyone who's tried functional
programming in Java or C++ has encountered this - it can be done, but it's
more tedious.  If all you want to do is e.g. (map somefun mylist), being
able to concisely define executable "objects" (closures), inline if
necessary, is very useful.

But from another perspective, the apply "method" of a closure can be used as
a low-level method dispatch mechanism, so closures can be, and are, used to
implement very effective objects with multiple methods.  Oleg Kiselyov has a
short article on the subject:
http://okmij.org/ftp/Scheme/oop-in-fp.txt

Used in this way, closures can be said to be richer than objects because
they can support many more capabilities than just a single language-provided
method dispatch mechanism.  With closures seen as a building block with
which to implement objects, it's clear that objects are a poor man's
closures.

But a Smalltalker might say hold on, if you're going to all the trouble to
implement these closure thingies in your language, since they're already a
lot like objects, why not go all the way and make them "real" objects that
can support an arbitrary number of methods, so that a closure is just one
special-case kind of object?  If your language only has these restricted
closures, and you're forced to build an object system on top of them, it's
clear that closures are a poor man's objects.

Given this tension between opposites, I maintain that the question of
closures vs. objects should really be a koan.  I'll take some koanic license
and combine Norman Adams (alleged source of "objects are a poor man's
closures") and Christian Queinnec ("closures are a poor man's objects") into
a single great Zen language master named Qc Na.  I'll also take the
un-humble step of inserting myself as student, since as I mentioned in the
last paragraph of this message:
http://www.ai.mit.edu/~gregs/ll1 ... -html/msg01488.html
...I believe I did in fact gain some enlightenment from considering these
two apparently opposing positions.  Here goes:

* * *

  The venerable master Qc Na was walking with his student, Anton.  Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?"  Qc Na looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."

  Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures.  He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system.  He learned much, and
looked forward to informing his master of his progress.

  On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures."  Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Closures are a poor man's
object."  At that moment, Anton became enlightened.

:)




原文:What's so cool about Scheme?