From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,73175d2d01a1b1dd
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.11.199 with SMTP id s7mr21622061pbb.5.1317030354420;
        Mon, 26 Sep 2011 02:45:54 -0700 (PDT)
Path: 
 lh7ni5212pbb.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: subprogram must not be deeper than access type
Date: Mon, 26 Sep 2011 09:45:53 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnj80ieh.i18.lithiumcat@sigil.instinctive.eu>
References: <slrnj7trhq.i18.lithiumcat@sigil.instinctive.eu>
 <818752663338654817.822041rmhost.bauhaus-maps.arcor.de@news.arcor.de>
Mime-Version: 1.0
Injection-Date: Mon, 26 Sep 2011 09:45:53 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
 posting-host="Mda950WjNwNLAFOE7yJXQw";
	logging-data="24053"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+Q0w93PhO/akQ6BIAA84lM"
User-Agent: slrn/0.9.9p1 (FreeBSD)
Cancel-Lock: sha1:jvuWsUgBYP7k3yyVjNl+CGK5mWo=
Xref: news1.google.com comp.lang.ada:18126
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: 2011-09-26T09:45:53+00:00
List-Id: <comp.lang.ada>

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