This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
Richard Kelsey <kelsey@xxxxxxx> writes: > Some discussion of the rationale would be helpful no matter > which choice is made. Good point---we'll try to address that with the next draft. The general rationale is, I think, that the compound data types appearing in many applications (say, abstract syntax trees, file mode bits, and so on) have subtype relationships that single inheritance models naturally. I personally find it quite useful, even though it needs to be used with care. More specifically, it also works to implement single-inheritance class systems, if you believe in and want one of these. Multiple inheritance sure would enhance the functionality, but I guess we we thought that the added usefuless was too small to justify the significant complications in semantics and implementation. > Personally, I haven't found single or multiple inheritance > to be particularly useful, but that doesn't make the current > proposal any more palatable. If inheritance is necessary, at > a minimum I think that the procedural form should allow multiple > inheritance as far as the predicates are concerned. I have trouble following your rationale---if you haven't found multiple inheritance useful, why is adding it better than leaving it out if single inheritance stays in? Also, could you elaborate what you mean by "as far as the predicates are concerned"? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla