[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: s-exprs + prototypes

> Date: Sun, 22 Jun 2003 22:59:46 -0400
> From: "Michael St . Hippolyte" <mash@brooklyndigital.net>
> 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.

I'm not sure what you mean by a "lazily-evaluated dynamic type system".
Care to elaborate?

Some of the object systems I've seen, such as CLOS-like object systems
supporting multimethods, have to do quite a bit of work to find the method
that corresponds to a given selector.  They have to consider the set of
argument types, look for a method that corresponds to those types, and if
it isn't found, look for the most specific method that is compatible with
those types (using the inheritance relationships to help with the
dispatching, BTW).  That seems to me to be a lot more intricate than just a
simple scoping problem.  Now, not all object systems work this way.  What
exactly are you proposing?

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

The distinction is that scoping (in the absence of objects) is less
controversial and there are fewer choices.  Basically it comes down to the
environment model of the language you're using.

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

Once again, you clearly have something in mind.  More details, please.