This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
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