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

On 2018-04-13, George Neuner <gneuner2@comcast.net> wrote:
> 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.


More problematic than the lexical conflicts is the whole business
of "virtual inheritance". If you don't use it, you end up with
with multiple copies of the same bases via different paths in the
multiple inheritance DAG.


It all has to do with the specification of C++ inheritance (and
everything else) being motivated by a specific locus of implementations:
how it works at the memory layout level with specific pointers, offsets,
tables and whatnot.


Before the C++ people specify anything, they first have to ensure that
some relatively cheap and fast mechanism can handle it at run-time.
That then guides how the specification is written, even if it is not
explicitly in the wording.


> 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?


Are they? Interfaces are only a workaround for lack of MI if you
take it for granted that a class must *declare* inheritance from
B before its instances are permitted to be substituted wherever
a B may be used.


If you do not take that for granted, then you don't need inheritance
at all.


In the Common Lisp object system that you mentioned, we can easily
specialize the same method to string or integer, even though those
are not related by inheritance. We just:


    (defmethod foo ((arg integer))
        ...)


    (defmethod foo ((arg string))
        ...)


The integer and string classes doesn't have to have a declaration
injected into them which them allows their instances to appear
as obj in (foo obj) calls.


So *that* motivation for MI is absent: we can take any class
or classes, and just use them in multiple method-based protocols;
as many as we want.




--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1

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