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

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

On 07.08.12 15:09, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue, 07
> Aug 2012 13:33:21 +0400:
> 
>> On 07.08.12 01:09, Vasiliy Molostov wrote:
> .....
>> Hence, the place where others want to learn how to call a
>> subprogram is not the place for aspects that apply in very
>> specific circumstances only. They never affect the text
>> of the call statement.
>>
> 
> Perhaps I am a bad reader but you have not explained - what the benefit to
> place Inline in a private part.


Premise 1: The reader is the only important person in Ada programming.
Premise 2: The reader wishes to learn from a package spec how to write
a call statement (essential knowledge: profile, contract, exceptions).
====
Conclusion: Anything that does not answer the reader's questions as stated
in premise 2 is in excess of what is needed, in general, and not beneficial.

> Why convention is an optimisation? <- "you still have unanswered question here"

I have answered this question twice. Specifically,
I have likened the two and pointed to the ground on which
the two aspects compare. I have *not* said that
convention *is* optimization, or vice versa. You may
have read this into my comparison of the reader's attitude
towards both, I think.

Again, if Ada.Strings.Fixed.Move has something with convention C,
then as the reader of Ada.Strings.Fixed I not only need
not care about that, thanks to Ada's separation of spec,
I don't want to be bothered with whatever mechanism
is used to make Move work. I want to be able to write Move,
and know what this does.

> Other things in your replacas while they are good in common I consider as
> demagogy here, sorry.

My impression is that you generalize a style that is useful
in your specific circumstances. I can't accept that as generally
useful and not as economically viable. Reason: I am the one who
always has to do the clean-up after a "pragmatic, cool" programmer
has left a company and I know the time it takes to make things
work in general, again.
Jobs: "Get this code to work in the new surroundings."
"Turn that clever hack into something that works when Xyz
changes", etc. You get allergic to things that should be
general, like a subprogram spec, but aren't because they
were written "pragmatically", and it takes time to sort
out which aspects are essential (influence the program's
output) and which aspects aren't.