Re: Why .ads as well as .adb?

["Randy Brukardt" <randy@rrsoftware.com>]

Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:f611bdb8-5a40-48bd-afe5-17de72bbe193@googlegroups.com...
>> On the other hand, I like it that I can get a first impression of an Ada
>> program by reading just the .ads files.

...
>Say, I need this idiom in 10% of packages. Why am I
>penalized in the remaining 90% and forced to write specs
>that are demonstrably not needed?

I think you have this percentage backwards. You need this idiom in a 
significant majority of packages, certainly in anything object-based. I 
would have given the percentages as more like 80% need it and 20% don't.

After all, anything that doesn't benefit from separate specs really 
shouldn't be in a package in the first place. It might be in a package since 
some other package got unmanageably large (Janus/Ada has a lot of these, 
especially because of the size limits when it originally was created), but 
my experience is that such things are impediments to understanding the 
program and in finding where things really are. So it is best to avoid them.

...
>> Apart from all the other reasons already given, keeping spec and body in
>> the same file can cause compilation-order problems.
>
>Only if you assume that the compiler reads the file only once and therefore
>must validate everything in a single pass.

There's two parts to this. The first part is true of almost every compiler 
(GNAT is a weird exception). That's in large part because compiler 
performance is mostly bound by I/O time (memory management overhead taking 
much of the rest); outside of optimization, compilation simply doesn't do 
enough to show up in a CPU monitor (and this has been true for decades, at 
least since the early 1990s). The less I/O a compiler does, the faster it's 
build times are going to be. (Which probably doesn't matter for one file, 
but it certainly matters for systems with hundreds of units.)

The other part is true, but seems irrelevant. The issue being the increased 
coupling of putting all of the source in one file (which I do do from 
time-to-time). Before one can compile a source file, all of it dependencies 
have to exist and be compilable as well. Which means that when the body and 
spec are together, you have to have much more of the program compilable 
before any part of it (and the files that depend on it as well) can be 
compiled. But compiling is the best way to stamp out mistakes, and it has 
been proven that the earlier that you can catch a bug, the cheaper it is to 
fix. Delaying compilation just makes it more likely that you've forgotten 
part of your intent before the problem shows up.

>Which is not the case anyway, not even in Ada (nor in C++). That's why this
>concept looks a bit archaic today.

The concept of decreasing coupling seems just as relevant today as it was 
when it was designed into Ada 83. After all, a well-designed unit will only 
reference a handful of things in the specification and many things in the 
body. Mixing them increases the coupling for the compiler and for the 
reader.

                                        Randy.


                             Randy.