Re: Closures versus objects

On 2/15/07, Wolfgang De Meuter <[email protected]> wrote:
> I think there is a big difference between objects and closures if you
> start thinking about inheritance.

I don't think the difference is that big.  I consider inheritance to be part
of the `machinery' of objects.  That is, when you invoke a method on an
object, you have to decide exactly what method you are going to run.
Inheritance gives you implicit rules that often match the ontological rules
you wish to model.  (Of course this is why inheritance `works'.)

When you use a closure to represent an object there are no implicit rules,
so you have to *explicitly* supply the code that figures out the method to
run.  Again, the rules are dictated by the ontological model, so you'll have
some standard `boilerplate' dispatch in the closure to implement them.

The difference is that the `object' version abstracts away the
boilerplate.  This
is a good thing if you can eliminate the details of method selection with one
overall mechanism.

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

I think that treating lexical scope as a `poor man's inheritance mechanism' is
a bad idea for the reasons you enumerate below:

> 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?

This is one reason I prefer CLOS-style object systems.  Since methods are
not encapsulated within objects, there is no temptation to mingle method and
field identifiers with the identifiers introduced through lexical
scoping.  I also
think the WITH-SLOTS macro of CLOS, which binds field names to lexical
variables, shouldn't be used.  If we use an explicit form to refer to
object fields
then there is no ambiguity.

> I'm not saying it is not impossible to come up with nice semantics for this.

I actually think it *is* impossible.  If you mix lexical scope with
object scope you
will *guarantee* the construction of a brittle system.

-- 
~jrm