From: | George Neuner <gneuner2@comcast.net> |
Newsgroups: | comp.compilers |
Date: | Thu, 12 Apr 2018 20:51:08 -0400 |
Organization: | A noiseless patient Spider |
References: | <49854345-f940-e82a-5c35-35078c4189d5@gkc.org.uk> 18-03-103 18-03-042 18-03-047 18-03-075 18-03-079 18-03-101 18-04-002 18-04-003 18-04-004 18-04-024 18-04-034 18-04-041 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="65489"; mail-complaints-to="abuse@iecc.com" |
Keywords: | OOP, history |
Posted-Date: | 12 Apr 2018 20:57:59 EDT |
On Thu, 12 Apr 2018 01:09:42 +0200, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> wrote:
>Am 10.04.2018 um 20:32 schrieb George Neuner:
>> On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
>> (Anton Ertl) wrote:
>
>> Smalltalk had/has single inheritence only, and it's dynamic dispatch
>> mechanism is very different from that of C++.
>
>Isn't *multiple inheritance* one of the features that C++ proved
>impractical? Which other languages support multiple inheritance?
No. It proved only that C++ wasn't able to accomodate conflicting
classes effectively. Lisp handles this same problem much more
effectively, so it isn't a generic fault of MI.
Moreover, most (all?) SI languages implement interfaces (abstract
classes). Interfaces mainly are a workaround for lacking real MI, so
why would they do that if it were useless?
C++ implemented interfaces also, but it did so because it's object
layout semantics did not allow for the merging of non-conflicting
members, and its dispatch semantics did not adequately address
predictable function dispatch in the case of "diamond" inheritance.
Lisp addresses both of these issues very well, and also handles the
issue of conflicting (by type) members.
>[Lots of languages have multiple inheritance. Python is one of the
>more popular these days. As you've seen, opinions vary about how
>useful it is. -John]
Obviously it depends on the specifics of the hierarchy. There is no
guarantee that MI will save you anything. But where interfaces are
commonly employed in SI languages, an implementation under MI might
well be less work.
It often is the case that a subclass has to reimplement something from
one of its ancestors, and it *might* be the case with MI that there is
a clash wrt handling something that has to be worked around. But
using interfaces, it is *guaranteed* that you will have to
(re)implement not just things that conflict, but everything in the
interface.
YMMV,
George
Return to the
comp.compilers page.
Search the
comp.compilers archives again.