[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reasons for withdrawal
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).
(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>?
(add-all <bag-of-apples> <bag-of-oranges>)
(intersection <set-of-primes> <set-of-2^n-1>)
> > 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.