At Wed, 29 Oct 2003 08:25:39 -0600, xxxxxx@freenetproject.org wrote:
>
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Wed, Oct 29, 2003 at 03:12:27PM +0900, Alex Shinn wrote:
> > At Tue, 28 Oct 2003 21:37:26 -0600, xxxxxx@freenetproject.org wrote:
> > You don't, however, need a full-blown, mother-of-all object systems for
> > this SRFI.  You just need single-dispatch for an single-inheritance
> > hierarchy, which could be done in a very simple SRFI.
>
> I know.  I note this in the Issues section, stating:
>
> "At the same time it is hoped that a future SRFI will specify a
> mechanism which will allow a portable and efficient implementation of
> collections to exist."
>
> I hope you'll agree that it is ultimately an implementation issue to get
> the dispatch right, but its not that difficult since it is a very simple
> form of dispatch.  Bugs will exist in implementations of anything, they
> can be fixed.

True, it is very simple, which is why I think it would be better to
specify it clearly first.  If you break things into small pieces there's
less confusion (and less to argue about).

A Scheme that implements this SRFI would end up using either their
native object system, a portable object system like TinyCLOS, or a
miniature dispatch system like bear suggested.  I'm worried that these
are not semantically compatible.  In the absence of a dispatch SRFI I'd
like to see the exact semantics specified in detail in SRFI-44 to avoid
future problems (and if it truly is simple then this will be a short
addition).  Items that seem to need clarifying:

   1) single vs. multiple inheritance
       - just say single!
       - if multiple, what CPL do you use?
   2) single vs. multiple dispatch
       - multiple is probably needed for *-union, etc.
       - if multiple, how do you resolve conflicts?
   3) abstract vs. concrete
       - can concrete classes be sub-classed?
       - can new abstract classes be made?
       - can abstract classes sub-class concrete classes?

In the absence of these we don't have clear guidelines for extensions to
this SRFI, and future extensions are likely to have conflicts with each
other and/or specific implementations of the dispatch mechanism.

--
Alex