Re: s-exprs + prototypes

["Michael St . Hippolyte" <address@hidden>]

On 2003.06.22 15:15 Anton van Straaten wrote:
> Steve Dekorte wrote:
> > 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.

The dispatch mechanism for an OO language, properly constructed, can be
trivial.  With a simple enough language, it's just a lookup of a name in a
context -- exactly what any lexically scoped language has to do anyway.
Even inheritance doesn't have to impose a significant burden -- if the
inheritance is based on a lazily-evaluated dynamic type system.

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

Well, yes it does, whether the programmer is aware of it or not.  As soon as
you have scopes, you have to have a way of differentiating one scope from
another, and calling the code associated with the imminent scope -- a
dispatch mechanism, whatever you may choose to call it.

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

I agree with you that OO systems usually come with a lot of baggage, but I
disagree that this needs to be the case.  In particular, if objects *are*
atomic functions, you get the best of both worlds -- trivial overhead (like
functional languages) and encapsulation/inheritance/polymorphism (like OO
languages).  Think of it as an OO language where the only methods are
constructors, and all variables are immutable.

(I suggest calling this genre FOOP, for Functional Object-Oriented
Programming.)

Michael

-----------------------------
Michael St. Hippolyte
http://www.bentodev.org