Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!newsfeed.internetmci.com!cpk-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!howland.erols.net!vixen.cso.uiuc.edu!uchinews!cbgw2.att.com!nntphub.cb.lucent.com!alice!allegra.att.com!dujardin
From: dujardin@allegra.att.com (Eric Dujardin)
Subject: Re: proposal for simple quasi-standard object system (straw person)
X-Nntp-Posting-Host: ode.tempo.att.com
Message-ID: <DwG8vG.GG2@research.bell-labs.com>
Sender: usenet@research.bell-labs.com (netnews <9149-80593> 0112740)
Organization: Lucent Technologies, Bell Laboratories
References: <4va0ms$j50@roar.cs.utexas.edu> <DwEM4n.7sz@research.bell-labs.com> <4vce5j$lor@roar.cs.utexas.edu>
Date: Tue, 20 Aug 1996 18:33:15 GMT
Lines: 70

In article <4vce5j$lor@roar.cs.utexas.edu>, wilson@cs.utexas.edu (Paul Wilson) writes:
|> In article <DwEM4n.7sz@research.bell-labs.com>,
|> Eric Dujardin <dujardin@allegra.att.com> wrote:
|>  >Flat classes would allow to implement various inheritance/subtyping schemes
|>  >on top of this system. For example, if types (or Java-like interfaces) are
|>  >added, method resolution could depend on subtyping or on inheritance.
|> Precisely. What I'm trying to propose is three different but somewhat
|> related things.
|> 
|>    1. Minimal underlying mechansims that a language implementor can
|>       provide to support the rest portably.  That is, the implementation
|>       of the object system should be mostly portable.  The main requirement
|>       of an underlying Scheme implementation is that it support a fast
|>       generic procedure dispatch cache.
|> 
|>    2. Minimal but usable default policies (language level features) that
|>       allow maximal lattitude for various implementors to add extensions
|>       without requiring others to do so. 
|> 
|>       If users want to write code relying only on the minimal features,
|>       it should work in any system---implementors should support the
|>       standard class definition facility.
|> 
|>       But even if implementors add extensions that are incompatible, and
|>       don't support the standard class-definition syntax, the resulting
|>       objects should still be interoperable.  Systems with fancy object
|>       systems will probably also have module systems, making it possible
|>       to use one syntax in one module, and another in another, but still
|>       communicate through singly-dispatched dynamically-typed generic
|>       procedures.
|>           
|> >It could
|> >also depend on several arguments (I may volunteer to implement that).
|> 
|> Cool.  It shouldn't be hard to do portable multiple dispatch on top
|> of a fast single dispatch.  Of course, if the underlying dispatch cache
|> supports multiple dispatch, that'll probably be faster.
|> 
|> I want to keep this minimal, though---multiple dispatch should probably
|> not be standard, at least initially, so that nobody will say "that's
|> too much trouble for me to comply with, because I already have my
|> own fancy object system."
|> 
|> (If people have no objection to single inheritance, I'm all for standardizing
|> it in the default language-level object system.  People would still be
|> free to implement other things (like delegation), so long as their objects
|> can interoperate.)
|> 

Agreed. It seems to me that for flexibility, the lowest level shouldn't 
make any assumption on the kinds of inheritance and message passing at 
level 2. To obtain cooperation, the lowest level only needs to
implement message passing, i.e. all objects are supposed to understand
abstract messages and execute the relevant procedures. Then level 2
could implement any policy to support message resolution, using the fast 
caches or another technique (the one that I have in mind for handling
multiple dispatch does not use caches, but dispatch tables).  Single
inheritance is fine for the standard level 2, especially since there
would be no typing either.


Eric



-- 
Eric Dujardin                                 dujardin@allegra.lucent.com
Lucent Technologies - Bell Laboratories
Room 2C-234, 600 Mountain Avenue, P.O. Box 636      Phone: (908) 582-7153
Murray Hill, NJ 07974-0636, USA                     Fax  : (908) 582-5809
