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.
On Thu, Oct 30, 2003 at 11:14:52AM +0900, Alex Shinn wrote: > At Wed, 29 Oct 2003 08:25:39 -0600, scgmille@xxxxxxxxxxxxxxxxxx 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, scgmille@xxxxxxxxxxxxxxxxxx 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: I'd like to see both, but I don't think SRFI-44 needs to be held up to wait for the former. > > 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. > 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). > 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. > - can new abstract classes be made? Sure. It merely implies a new set of generic operators. > - can abstract classes sub-class concrete classes? At first blush I can't think of any reason to do so. > > 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. I agree, this is worth doing. Scott
Attachment:
pgp1C0YEd47ZO.pgp
Description: PGP signature