Re: RE: rename missing in Text_IO

[Ted Dennison<dennison@telepath.com>]

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