Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 07.08.12 01:12, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue, 07 Aug 2012 02:10:08 +0400:
>
>> And, just like it is not normally important to know optimization
>> issues when writing a call, it is not important to know
>> the convention of an import when writing the call (of the
>> Ada subprogram from the package spec).
>
> It is important since we all here working with libraries of already compiled code. We need it.

Frankly, if you are working with compiled libraries made for
re-use and your compiler's linking machinery cannot handle the
two typical setups that are representatives of this discussion,
viz. library-in-mode-optimal and library-in-mode-debugging,
then maybe switch compilers but don't put all kinds of program-
specific, compiler-specific, debugger-specific stuff in a public
package spec. That's your quality of implementation problem with
your tools, not the readers of specs of re-usable packages and
that's my point.

Example:
...
Ada.Strings.Fixed.Move (...);
...

So we have a user of package Ada.Strings.Fixed who wishes to know about
Ada's Move. Would he normally have to learn---if A.S.Fixed has been compiled
already---certain aspects related to translation and debugging for
some implementation for some processors for some program?
No! He should be able to write Move and know what Move does.
Should he be able to learn about optimization opportunities
when Move becomes part of some important inner loop?
Yes! For example, he should be able to see whether or not
Move can be inlined.  But this case is special and, being a special case,
should not clutter the specification of Move in Ada.Strings.Fixed!



>> This is why I have
>> likened optimization to calling conventions. They share the
>> same degree of irrelevance from the caller's perspective.
>
> What is the perspective of that caller you mean?

Oh, well, the standard perspective of the scenario Ada was made for:

Larger pieces of software built independently such that team A
using package P1, and unrelated team B also using package P1,
in unrelated programs Prog_X13 and Prog_Z24 need not normally
know about internals of P1, or about how P1 was translated for
team B (whom they likely never heard of), or about how P1.Sub_98
is called by team A's Prog_X13, but not called in the same way
by team B's Prog_Z24. Or what compiler might be used and whether
or not P1.Sub_98 cannot be inlined in version 1.23 of compiled
distribution of P1 for teams C, D, but not for team E.

These questions are interesting in specific situations, but
they should not intrude the specification of public P1.Sub_98.