RE: s-exprs + prototypes

["Anton van Straaten" <address@hidden>]

Steve Dekorte wrote:
> On Sunday, June 22, 2003, at 12:42 AM, Anton van Straaten wrote:
> > But you've built Lisp on top of a system which inside its objects,
> > already supported functions - it's a bit like building bricks out
> > of houses.
>
> Consider this question:
> What is the difference between a method in an object and a function in
> a scope?

The answer to that is quite central to some of the issues I have with OO.  A
method in an object is accessed through a dispatch mechanism which is built
into the core of an OO language.  The programmer has little or no control
over this dispatch mechanism, short of modifying the language - it comes
along for the ride in every object, whether it's appropriate or desirable or
not.  As Mike pointed out, this dispatch mechanism typically includes logic
to support inheritance, and may encapsulate other fixed behaviors.  In some
languages, it inextricably ties the method to an object, even if the method
doesn't need access to any objects.

A function in a scope is only accessible within that scope.  If a programmer
wants to expose a function more widely, that can be done by any appropriate
means - it doesn't have to involve a predefined and unmodifiable dispatch
mechanism which may not be appropriate to the task.

I'm well aware that you can use objects to simulate closures and functions,
and vice versa.    I've done it myself, in both directions, in various
languages.  All I've been saying in this respect is that in practice, object
systems I've worked with have had more baggage related to machinery to
support the operation of the object system, than do systems which support
atomic functions.  That's understandable: object systems have more built-in
behaviors.  But you can't take it for granted that a particular set of
built-in behaviors will be universally appropriate.

In other messages, you've made a consistency argument: if everything is not
an object, you can run into consistency problems, the inability to treat
values polymorphically, and so on.  But that's really an issue of
interfaces.  Typical OO systems make a mistake in tying this issue to their
particular implementation of message dispatch, which in turn may involve a
particular notion of *implementation* inheritance, and so on.  If you want a
consistent system, do a full separation of interface from implementation, so
that the "object system" behind the scenes doesn't really matter - in fact,
there might be more than one.  That's one of the issues that led me away
from OO originally.

Anton