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=1.9 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA, UNCLOSED_BRACKET autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,cfb2002511b830ab X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.39.100 with SMTP id o4mr26395166pbk.0.1322495493787; Mon, 28 Nov 2011 07:51:33 -0800 (PST) Path: lh20ni30975pbb.0!nntp.google.com!news1.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 28 Nov 2011 16:49:44 +0100 From: Georg Bauhaus 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: <4ecfc4c4$0$6579$9b4e6d93@newsspool3.arcor-online.net> In-Reply-To: Message-ID: <4ed3ad98$0$6573$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 28 Nov 2011 16:49:44 CET NNTP-Posting-Host: 03b6abe6.newsspool3.arcor-online.net X-Trace: DXC=F;nc\616M64>:Lh>_cHTX3j=GFm:_A[4[28 X-Complaints-To: usenet-abuse@arcor.de Xref: news1.google.com comp.lang.ada:19212 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2011-11-28T16:49:44+01:00 List-Id: On 26.11.11 19:13, Natasha Kerensikova wrote: > So maybe it would make sense to keep the > access-to-procedure Callback argument, and create an > Option_Error_Handler class, whose default value in Process would be > something that just raises Option_Error (which would by the way make > Process body cleaner by not having to check null access). > ... > While I certainly agree with this in general, in this particular case > I'm skeptical about (2), since I can't think of any example where error > handlers are not fatal, which leaves only one handler that only has to > communicate with itself. Two use cases for stateful handlers that I can think of are 1) -v -v ... increasing verbosity, i.e., handling means counting the number of times an option has occured 2) Two options -A and -B must not occur ensemble, in any order or frequency (This is "inspired" by really complicated setups, such as the nightmarish command line interface of ffmpeg.) In either case, the handlers would have to have a way to be informed about prior occurrences. > Yes, I'm completely sold on the idea of using a dispatching call instead > of error handler accesses. And still unsure about the normal handler. Both mechanisms should work. Though, for reasons of reduced complexity, and streamlined interface, I'd prefer just one mechanism used for either of regular handlers and error handlers. Doesn't hurt, and if later the regular callback mechanism needs extension, the interface of Process needs little change. Do not worry about efficiency of indirect calls. It seems that there is very little difference at the assembly level, in particular when the compiler "dispatches" to the right procedure at compile time, as is the default with Ada. (If the programmer has not requested runtime dispatching explicitly.) For illustration, in traditional Ada, one may pass a callback as a generic formal subprogram. There is then no pointer. The following example is from a translation with optimization turned on, but without any inlining and checks turned off: using a procedure pointer: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 ec 08 sub $0x8,%esp 6: c7 04 24 01 00 00 00 movl $0x1,(%esp) d: ff d0 call *%eax f: c9 leave 10: c3 ret using a formal generic procedure: 30: 55 push %ebp 31: 89 e5 mov %esp,%ebp 33: 83 ec 04 sub $0x4,%esp 36: c7 04 24 02 00 00 00 movl $0x2,(%esp) 3d: e8 de ff ff ff call 20 42: c9 leave 43: c3 ret Don't know if there is a difference at all in terms of efficiency. However, with checks turned on, the pointer version show a longer list of instructions than that of the generic version. > Having it a type discriminant like you suggest feels like an abuse of > the type discriminant feature, but I cannot manage to tell why (and I > might be wrong, considering I'm still too new to have accurate > feelings). If you remember that a discriminant acts a a subtype constraint, your worries might be fewer: Once the constraint has a value, the value will suitably restrict the set of possible values of the type. This might also mean that operations can now select specific behavior depending on the discriminant constraint. This constrains the set of possible behaviors. > However, is there anything wrong with having something like the > following? > > generic > type Option_Id is (<>); > package Natools.Getopt_Long is > Option_Error : exception; > package Handlers is > type Argument_Handler is abstract tagged null record; > procedure Missing_Argument > (Handler : in out Argument_Handler; > Id : Option_Id); -- implementation raises Option_Error; > -- others handlers, maybe including regular argument callback > end Handlers; > procedure Process ( -- arguments to be written later > end Natools.Getopt_Long; > > Or is the inner package looking for trouble? No, seems fine.