From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9eccdbc9cfa1c9b9
X-Google-Attributes: gid103376,public
From: Jean-Pierre Rosen <rosen@EMAIL.ENST.FR>
Subject: Re: OO Idiom: Interfaces for derived classes
Date: 1996/03/22
Message-ID: <199603220939.KAA00777@email.enst.fr>#1/1
X-Deja-AN: 143628945
sender: Ada programming language <INFO-ADA@VM1.NoDak.EDU>
x-sender: rosen@email.enst.fr
comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
content-type: text/plain; charset="us-ascii"
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Windows Eudora Light Version 1.5.2
Date: 1996-03-22T00:00:00+00:00
List-Id: <comp.lang.ada>

At 15:34 21/03/1996 +0100, you wrote:
>Dear Ada users,
>
>I am currently investigating Ada for OO programming, and I would like
>to ask you for your comments wrt a question of programming style
>
>After studying the ARM and "Ada as a second language" (Normal
>H. Cohen, 1996), I came to the conclusion that Ada as a language does
>not directly address/ has no apparently obvious approach wrt
>
>   whether it is desirable to separate interfaces for clients of
>   classes vs. derived classes, and if so, how to implement the
>   separation.
We discussed this issue at length during some Ada-France meeting. Here is a
summary of our conclusions.

There are two views of derived classes. Suppose you are the provider of some
reusable software components, and you want to provide guarantee on your product.

1) The product as a whole is a hierarchy of classes (for example, a set of
widgets).  For design as well as for efficiency reasons, it makes sense to
have derived classes defined in child packages, and since it is YOUR
product, you don't mind derived classes accessing the parent's private part.
Actually, without hierarchical libraries, you would provide the  whole stuff
as one package. Child packages make it just more convenient  for the user to
"with" only the features that are needed.

2) The product is a set of classes, that are INTENDED to be extended by the
user. The user should not do this in child packages, because you cannot
guarantee your product if the *user* accesses the private part of the
parent. Actually, the  guarantee would have a clause "guarantee is void if
classes are derived in child packages", similar to a TV set with a clause
"guarantee is void if the user opens the back pannel".

So both views serve are useful, for different purposes.
+------------------------------------o-------------------------------------+
| P-mail:                            | E-mail: rosen@enst.fr               |
|   ADALOG - 27 avenue de Verdun     |    Tel: +33 1 46 45 51 12           |
|   92170 Vanves - FRANCE            |    Fax: +33 1 46 45 52 49           |
+------------------------------------o-------------------------------------+