Re: subprogram must not be deeper than access type

[Natasha Kerensikova <lithiumcat@gmail.com>]

Hello,

On 2011-09-25, georg bauhaus <rmhost.bauhaus@maps.arcor.de> wrote:
> Natasha Kerensikova <lithiumcat@gmail.com> wrote:
>> type String_Accumulator_Linked_List (Builder : Accumulator_Builder)
>>    is new String_Accumulator_Stack with private;
>
> As an aside, I'd consider an alternative type
> String_Accumulator_Linked_List that
> has a stack, rather than being a stack.
> From this choice a more flexible design 
> might follow.

That's a great idea, thanks a lot for pointing it out. I still don't
intend to change my String_Accumulator_Linked_List, since it's goal is
really to be the simplest possible implementation of the interface, only
to have some real code to run.

However when things get more mature, I will probably want something more
flexible and easier to integrate with other components, and that's when
your suggestion will certainly be useful.

> Also, whenever an anonymous type
> seems to solve a design problem,
> something might be in bad shape
> at a higher level.

Actually I wonder whether there is a design problem at all.

The thing is, I'm still a beginner in Ada and probably also in real
software engineering. I'm probably tainted by more than a decade of
practising C, following almost a decade of 386 assembly as my first
programming language. I genuinely don't see anything wrong with the
design, but I might very well be missing something, hence my exposing it
to c.l.a. criticism.

Moreover, now that a solution is known, I'm still not convinced about a
problem in the design: the use of named access to subprogram types is
not required by the design, and it is not even required by the
implementation. I named the access type only to make the program text
clearer (for humans).

Having read the Rationale 2005, I understand now that naming an access
type is far from being equivalent to text replacement. A slightly less
readable program text is a small price to pay for the extra safety.


Thanks for your comments,
Natasha