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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,cfb2002511b830ab
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.59.229 with SMTP id c5mr11942970pbr.6.1322239173392;
        Fri, 25 Nov 2011 08:39:33 -0800 (PST)
Path: 
 lh20ni17049pbb.0!nntp.google.com!news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 25 Nov 2011 17:39:31 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Starter project: getopt_long in Ada
References: <slrnjcushg.vl6.lithiumcat@sigil.instinctive.eu>
In-Reply-To: <slrnjcushg.vl6.lithiumcat@sigil.instinctive.eu>
Message-ID: <4ecfc4c4$0$6579$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 25 Nov 2011 17:39:32 CET
NNTP-Posting-Host: 0c650faf.newsspool3.arcor-online.net
X-Trace: 
 DXC=E8Vh`@M]CN1^8FBo0_81f>McF=Q^Z^V384Fo<]lROoR18kF<OcfhCO;FK5>jeYMIE?nc\616M64>:Lh>_cHTX3j=A;kUQM?n1@1
X-Complaints-To: usenet-abuse@arcor.de
Xref: news1.google.com comp.lang.ada:19170
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2011-11-25T17:39:32+01:00
List-Id: <comp.lang.ada>

On 25.11.11 11:47, Natasha Kerensikova wrote:

> So I wrote a Getopt_Long package, along with a test suite, that can be
> found at:
> http://fossil.instinctive.eu/natools/dir?ci=tip

Looking at Natools.Getopt_Long.Process, there is one design
that I think is less clear than could be, seen from the use
case. If I were to write the event handling procedures, I'd be
noticing that the current design suggests writing a larger number
of "linguistically" unconnected subprograms to be passed
to Process. But, in fact, they will likely be logically connected
subprograms, all to do with parsing the same command line.

I'd prefer these handlers to be "linguistically" collected in
one place (and a different sets of handlers collected in
different places, respectively). In order to achieve this,
an abstract type can state the list of handling procedures,
with null defaults for operations the programmer does not
wish to do anything special. Defining this type has the
advantages that it makes programmers write software organized
into typed structure, yielding

1) definite places to look for the handling procedures
2) handlers that can share common data for communicating
   parsing state among them
3) human readers that know about 1 and 2 because they can
   look for concrete types derived from the abstract type.

I think the advantages outweigh a minor loss in flexibility,
if you'd want to call flexibility the ability to pass a
collection of subprograms each declared just anywhere.

Influencing the shape of this type, Process's parameters
such as Posixly_Correct might mean that the handling
procedures may want to determine whether or not Posixly_Correct
is true.

So, then, my first idea will be along these lines:

package Natools.Handlers is

    type Id_And_Argument_Handler
       (Posixly_Correct :  Boolean;
        ...)
    is abstract tagged private;

    procedure Callback
        (Handler : in out Id_And_Argument_Handler;
         Id : Option_Id;
         Argument : String) is abstract;

    procedure Missing_Argument
        (Handler : in out Id_And_Argument_Handler;
         Id : Option_Id) is null;

    etc.

end Natools.Handlers;


Then, the parameter profile of Natools.Getopt_Long.Process
beceomes shorter:

package Natools.Getopt_Long is

    etc.

    procedure Process
       (...
        Actions : Id_And_Argument_Handler'Class;
        ...);

    etc.

end Natools.Getopt_Long;

I did not look at the implementation.


- Georg