Re: Closures versus objects

I think there is a big difference between objects and closures if you  
start thinking about inheritance.

With closures, you only have "lexical" inheritance; i.e. the  
inheritance hierarchy aligns with the nesting hierarchy.

Consider a language that has an "object" keyword to create objects ex- 
nihilo (like "lambda") but which also allows one give an expression  
whose value is to serve as a parent-object that is to be used by a  
delegation mechanism.

		myObject = object (parent) { .... }

Now every object needs "two" parent pointers: the object-oriented  
parent and the closure-oriented next-frame pointer that is needed to  
implement nesting. Now consider a method that contains a variable  
reference "x". Where is x to be looked for? In the lexical parent? Or  
does one have to follow the delegation chain? I'm not saying it is  
not impossible to come up with nice semantics for this. But for me  
objects and closures are not two sides of the same coin :-)

Wolf

On 16-feb-07, at 04:46, Spencer Schumann wrote:

>
> Closures are good at capturing bindings ("fields") without the need
> to declare what you want to capture upfront. If you change your mind
> about what to capture, there is only a single place that you have to
> change. It's so easy to do this that you typically don't even realize
> that your "objects" have changed their "layouts". With objects, when
> you want to create new ones that should get more fields, you have to
> change the corresponding class definition to do so as well (at least
> in the mainstream OOP languages).
>
>
> I've long considered closures to be "lightweight" objects, and this  
> comment points out a fundamental reason for this.  In my view, the  
> "killer app" for closures is in callback functions, whether used as  
> event handlers or as inputs to higher order functions like map.
>
> Objects combine the functionality of closures with a module  
> system.  This is especially true in languages like C++ that don't  
> have a separate module system, and objects are often used to fill  
> the gap.  The other extreme is found in Perl, whose object system  
> is implemented in terms of packages.  Sometimes, the addition of  
> the namespace control objects provide is helpful for structuring  
> code; other times, it isn't needed and just gets in the way.
>
> - Spencer