Re: Reasons for withdrawal

[Alex Shinn <foof@xxxxxxxxxxxxx>]

At Wed, 29 Oct 2003 22:42:25 -0600, scgmille@xxxxxxxxxxxxxxxxxx wrote:
> 
> On Thu, Oct 30, 2003 at 11:14:52AM +0900, Alex Shinn wrote:
> >
> >    1) single vs. multiple inheritance
> >        - just say single!
> >        - if multiple, what CPL do you use?
> 
> Lets say single.  Its conceivable that a datastructure could support
> more than one type (list set, list bag), but I think that in that case
> you just make two collections instead.

A more common example might be the hash-table (dictionary) + av-tree
(sequence), which allows you both O(1) access and O(n) ordered
enumeration.  The order can be either a < predicate or by insertion
order into the dictionary.  These are actually fairly useful data types
that Perl, for a start, has standard modules for.

You can get around this without multiple inheritance though, it just
bloats your hierarchy and code a little.

> >    2) single vs. multiple dispatch
> >        - multiple is probably needed for *-union, etc.
> >        - if multiple, how do you resolve conflicts?
> 
> Could you illuminate a potential conflict (I believe you, I just want 
> some concrete things to think about).

Given

  (collection= <set> <bag>)  

do you dispatch on the <set> or on the <bag>?  Do you allow overloading
a dispatch for the particular case of <set> & <bag>?

Also

  (add-all <bag-of-apples> <bag-of-oranges>)

  (intersection <set-of-primes> <set-of-2^n-1>)

etc.

> >    3) abstract vs. concrete
> >        - can concrete classes be sub-classed?
> I would like to say no, for simplicity.  You could subclass in the 
> implementation in order to make two collections, but two concrete 
> collections cannot inherit from each other, only from the generic super 
> classes.  I could be argued out of this position.

Well, this makes getting around single inheritance harder.

> >        - can new abstract classes be made?
> Sure.  It merely implies a new set of generic operators.

OK.  I forgot to ask about new methods - are they allowed?

The next thing the SRFI really should provide is the syntax for the
above operations, like (define-collection-type ...), otherwise you are
precluding in advance any extensions from being portable.  They would
have to go through non-trivial rewriting for every dispatch
implementation they are to be ported to.

-- 
Alex