Re: language design after Algol 60, was Add nested-function support

George Neuner <gneuner2@comcast.net>
Thu, 12 Apr 2018 20:51:08 -0400

          From comp.compilers

Related articles
[15 earlier articles]
Re: language design after Algol 60, was Add nested-function support DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2018-04-11)
Re: language design after Algol 60, was Add nested-function support derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2018-04-11)
Re: language design after Algol 60, was Add nested-function support DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support bc@freeuk.com (bartc) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support rpw3@rpw3.org (2018-04-12)
Re: language design after Algol 60, was Add nested-function support bc@freeuk.com (bartc) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support gneuner2@comcast.net (George Neuner) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support gneuner2@comcast.net (George Neuner) (2018-04-12)
Re: language design after Algol 60, was Add nested-function support martin@gkc.org.uk (Martin Ward) (2018-04-13)
Re: language design after Algol 60, was Add nested-function support martin@gkc.org.uk (Martin Ward) (2018-04-13)
Re: language design after Algol 60, was Add nested-function support albert@cherry.spenarnc.xs4all.nl (2018-05-05)
| List of all articles for this month |

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.