Re: questions on Ada openGL binding in the GLOBE3D packages

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccpq795odd.fsf@shell01.TheWorld.com...
> Brian Drummond <brian@shapes.demon.co.uk> writes:
>
>> "Making code look the same as C" is ... not unambiguously better!
>
> True.
>
> But sticking closely to the C does have the advantage that
> the binding doesn't need a whole lot of documentation (which
> must be maintained) -- you can just refer to the C docs.
> A thick binding requires a lot of documentation.
>
> IMHO, the name changes are so systematic in this case, that
> it's close enough -- you can still refer to the C docs,
> and do the trivial translation in your head.  And the Ada names
> really are more readable.  I think it's the right choice,
> especially since the standard actually suggests doing it
> this way in languages that have a proper module system.
>
> What if you had a system originally written in Ada (with appropriate use
> of overloading), and you wanted to make a C binding?  In that case it
> would be impossible to make the names the same.
>
> I once wrote an Ada binding to some C code where every C function
> returned an 'int' as an error code, with 0 meaning "success".
> I did it in two layers.  A thin binding that worked the same
> way, returning Interfaces.C.int.  Then a layer on top of that
> that turned the error codes into raising an exception.  The second
> layer is such a systematic change that I think it can still
> be considered "thin" -- thin enough that the C documentation
> still makes sense.

I think calling that "thin" is dubious. I call the technique "medium" for a 
lack of a better term, and it has to include normalizing the names, adding 
appropriate defaults, and using Ada parameter modes appropriately (along 
with raising exceptions). But I agree that it makes reading C documentation 
easier than for a true "thick" binding -- the problem being, that no one 
should be forcing Ada programmers to read C documentation. Cost 
considerations of course make that necessary sometimes, but even then I 
would hope that there would at least be some Ada-specific documentation 
covering common use-cases.

                                          Randy.