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.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,24a59fbc07128ff8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-07 11:03:40 PST Path: newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9d6ahn$157$1@nh.pace.co.uk> <9d6h07$3b3$1@nh.pace.co.uk> Subject: Re: RE: rename missing in Text_IO Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Mon, 07 May 2001 14:03:13 EDT Organization: http://www.newsranger.com Date: Mon, 07 May 2001 18:03:13 GMT Xref: newsfeed.google.com comp.lang.ada:7277 Date: 2001-05-07T18:03:13+00:00 List-Id: In article <9d6h07$3b3$1@nh.pace.co.uk>, Marin David Condic says... >parameters. And yes, I too hate the error-code returns and usually resort to >either a set of enumerals for the statuses or exceptions or some combination >thereof. My current favorite trick is to just raise a single "Foo.Error" exception for any C error condition in each package. There are obviously some situations where this would be undesirable, but you'd be suprised how often its sufficient. Sometimes when extra info might be in order for diagnosis, it can just be put into the execption message. >I might be willing to help out here, but I'm wondering about proper >guidelines. It wouldn't help much to have a dozen guys each developing >package specs that look substantially different to cover the various parts Yeah, it would all need to interoperate. That's part of why I wanted to fob the job off on someone else. My bindings aren't really that good for a base right now, since a lot of basic Win32 stuff that everyone is liable to use isn't there (with the notable exception of process id's). >of the Win32api. The intelligent thing to do would probably be to parallel >the Win32ada packages. Maybe there's a "Ada_Win32ada" for every "Win32ada" >where the sole job is to Ada-ize the types, parameters, return statuses, Nearly all of that crap in Gnat's Win32 package is special String and Void pointer types that I never pass back to the user anyway. :-) The problem with doing things this way is that when you abstract away some of the C cruft, a lot of that organization doesn't make any sense. For instance, the Windows NT/2K "performance data" that you need to parse to get stuff like a what executable a process is using, is entirely accomplished using registry calls. But if abstracted down to something like Get_Executable_Name (Process.ID) Then it doesn't make much sense to put this call in a "Registry" package. Another issue is that a lot of times the original C libraries aren't very well organized in the first place. For instance, the Win32 process and thread stuff is stuck into a huge 8 thousand line header file along with basic File I/O, serial I/O, process syncronization stuff like pipes and mailslots and semaphores, object priveleges and ACLs, computer and user names, etc. My current bindings just have a single "Process" package for Win32 processes. I don't think I'd want to make a Win32.Base_Services package and put all that crap into it. >etc. There would need to be some guidelines & examples of how to translate >to something that at least looks fairly regular across all the packages. >Otherwise, we'd just end up with our own proliferation of Ada types, >subtypes, etc. Generally I try to stick to Strings, Integers, private types, and the odd enumeration here or there. But some specific guidlines would indeed be required, or I'm afraid I'd spend all my time redesigning submissions. Ick. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com