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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@notmyhomepage.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Why .ads as well as .adb?
Date: Sun, 2 Jun 2019 22:14:13 +0200
Organization: A noiseless patient Spider
Message-ID: <qd1amm$g0m$1@dont-email.me>
References: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com>
Reply-To: nonlegitur@notmyhomepage.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 2 Jun 2019 20:14:14 -0000 (UTC)
Injection-Info: reader02.eternal-september.org;
 posting-host="65d0b80b6fed159ea49860ea30f3e4d2";
	logging-data="16406"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX199RVc2BDXzuG/LUK8V1irHxo+bQ+fhnkY="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
 Gecko/20100101 Thunderbird/60.6.1
Cancel-Lock: sha1:CBsHchivQqIqhZ8NUO0AaQNTiJ8=
In-Reply-To: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com>
Content-Language: de-DE
Xref: reader01.eternal-september.org comp.lang.ada:56435
Date: 2019-06-02T22:14:13+02:00
List-Id: <comp.lang.ada>

On 02.06.19 02:48, John Perry wrote:
> Hello
> 
> I understand that Ada, like Modula-2 and Modula-3, and arguably like C++, requires a definition file (.ads) as well as an implementation file (.adb). With Oberon, Wirth moved away from definition files, using a symbol to indicate which module identifiers should be exported. (Someone else may have done this before him; it's just that I'm most familiar with this history.) Most languages I'm familiar with these days do something similar, either via public/private or some other mechanism.

Not entirely true, IMO, insofar as other languages offer to separate
the interface from all implementations, using abstract classes,
or protocols, as in Swift, say. On top of this, Microsoft has
introduced partial classes.

By not extracting the interface like in Oberon style (which
also features abstract classes IIRC), but instead by providing
the interface as a separate entity, effects are generated that
can be seen as beneficial in some business situations:

- there is more flexibility in trying out different implementations,
   simply through software configuration;

- teams can work separated from each other as needed, without the
   project having to distribute all of the implementation to everyone.

 From a configuration point of view, Ada's *separate* units are
an additional feature that may be useful in similar situations.
For example, separate units can provide debugging/tracing/whatever
editions of a piece of software so that neither the specification
nor the body stub of the unit needs to be changed whenever the
configuration is changed. This effect is transitive, at all call sites.