Re: Multiple procedures in the same adb file?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 15-01-11 21:51 , Robert A Duff wrote:
>> It is unwise to have procedures outside of packages
>
> Why "unwise"?

Because sometimes you need to add new stuff (another related procedure,
for example), and then there's no good place to put it.  If the existing
procedure is in a package, then that's where you put it.

This happened to me:  Existing code:

    function Some_Root_Package.Some_Function(...) return String;

Now I happen to know that it always returns String(1..20).
And returning known-length strings is more efficient,
and this one is a bottleneck, so it's worth changing to
something like:

    subtype String_20 is String(1..20);
    function Some_Function(...) return String_20;

But that doesn't work without adding a new package, which breaks
compatibility.  And this was a widely-used library, so I couldn't do
that.  And String_20 really doesn't belong in Some_Root_Package,
nor anywhere else than the package that Some_Function is (directly) in
(which didn't exist!).

If the original programmer had put Some_Function in a child package
Some_Root_Package.Some_Package in the first place, then I wouldn't have
had these problems.

I admit: these concerns are only significant for widely-used libraries.
If I had been working on a program instead of a library, I would have
just moved Some_Function into a package, and modified all the call
sites.  But it's probably a good idea to get in the habit of using
"library-programming" style even when doing "program-programming",
if it's not too much trouble.

Besides, it complicates the language quite a bit to have misc stuff
allowed as compilation units (e.g. task body subunits).  I would prefer
that the only unit of separate compilation be the package (and maybe
generic package).

>... I agree it is unusual, but I find it is sometimes useful,
> in particular to have subprograms which are children of packages but are
> their own compilation units. In a layered architecture, such subprograms
> are sort of in a layer between the higher layer that contains the
> declaration of the parent package, and the lower layer that contains the
> body of that package.

Sure, but you can do that with another package just as well as
with a procedure.

> In language-lawyer terms, perhaps such subprograms are not really
> "outside of packages", because child units are in some sense "inside"
> their parents, but the child subprograms are not "inside" any package in
> terms of source-code files.

Yes, you're right.  In fact, everything is logically nested within
package Standard, so everything is in a package.  But I meant that
everything should be physically/textually nested within a package,
and packages (and generic packages) should be the only
separately-compiled things.  And main procedures should be
(textually) in packages, instead of as standalone procedures
(and that part is not Ada -- just my preference for how it ought
to be!).

- Bob