Path: csiph.com!feeder.erje.net!2.us.feeder.erje.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Subject: Re: OOP language design after Algol 60, was Add nested-function support
Date: Sat, 14 Apr 2018 13:40:15 -0400
Organization: A noiseless patient Spider
Lines: 90
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <18-04-066@comp.compilers>
References: <49854345-f940-e82a-5c35-35078c4189d5@gkc.org.uk> <18-03-103@comp.compilers> <18-03-042@comp.compilers> <18-03-047@comp.compilers> <18-03-075@comp.compilers> <18-03-079@comp.compilers> <18-03-101@comp.compilers> <18-04-002@comp.compilers> <18-04-003@comp.compilers> <18-04-004@comp.compilers> <18-04-024@comp.compilers> <18-04-034@comp.compilers> <18-04-041@comp.compilers> <18-04-051@comp.compilers> <18-04-057@comp.compilers>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="3136"; mail-complaints-to="abuse@iecc.com"
Keywords: OOP, design
Posted-Date: 14 Apr 2018 15:05:31 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: csiph.com comp.compilers:2078

On Fri, 13 Apr 2018 10:22:03 +0200, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> wrote:

>Am 13.04.2018 um 02:51 schrieb George Neuner:
>> 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:
>
>> 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?
>
>Interfaces don't have all the problems arising from multiple
>inheritance. I can see only the disadvantage, that duplicate code may be
>required to implement the same interface in multiple classes. But see
>below...

Addressing your next point, interfaces don't easily solve the problem
that class A really IS-A class B and also IS-A class C.

>I've learned to distinguish class aggregation and composition by asking
>whether it *is* something, or *has* something. A house *has* a roof, but
>it *isn't* a roof, so it does not inherit from a roof class. This way I
>never felt a need for multiple inheritance in my programs. But perhaps
>outside my restricted experience there exist other needs...

HAS-A relationships also can be handled by container delegation if the
object system supports it.  E.g., the house object can contain a roof
object and "roof requests" sent to the house can be forwarded to the
contained roof.

IMO, this is a really useful feature that too few object systems
support.



The distinction between IS-A and HAS-A is something that isn't really
addressed by MI inheritence.  But that isn't to say that it couldn't
be.  Something like "implements" (more below) in an MI language could
be used to inherit preserving the HAS-A distinction for some suitable
predicate.

But IMO it is more natural to ask if something DOES <foo> or IS
<fooable> rather than to ask if it HAS some property <foo>. Obviously,
it's the same question - but the way in which it is asked implies a
slightly different semantic - one which MI answers directly [modulo
class naming] without needing any distinction of interfaces. YMMV.


>> 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.
>
>An interface can be implemented by a (class type) component of a class.
>Then only the specific dependencies between both classes have to be
>implemented explicitly. In Delphi the "implements" keyword implements
>such object delegation, in addition to method delegation.

But not all languages are so kind.

The problem is in unrelated classes that need to implement the entire
interface.  Consider, e.g., serializable, or displayable - in many
languages you would end up reimplementing the entire interface in
every branch of your heirarchy, with overrides in virtually every
subclass.

The result is that some languages now have many such things built-in -
either implicitly, or via wizard mechanisms like "implements".  Lots
of built-in functionality takes the sting out of using uncooperative
languages that make it hard (or impossible) to implement such
functionality yourself.  Unfortunately, it also tends to blind the
users to the limitations of the language ... until they try to do
something the language just won't permit, and then b*tch about needing
"foreign" functions and having to do things in C or assembler.

The "implements" mechanism saves work in SI languages, but it is less
useful in an MI language where any class can simply inherit whatever
functionality it needs.


>DoDi

YMMV,
George