Re: OpenGL in Ada

[Warren <ve3wwg@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

Gene expounded in
news:2074b3a5-12f3-4260-a2ad-f15ed251e378@d16g2000yqb.googlegroups.com: 

> On Jul 9, 1:38�pm, Shark8 <onewingedsh...@gmail.com> wrote:
>> On Jul 9, 9:11�am, Gene <gene.ress...@gmail.com> wrote:
>> > On Jul 7, 10:42�pm, Shark8 <onewingedsh...@gmail.com> wrote:
>>
>> > > Hello everyone,
>> > > I posted about wanting to write an OS in Ada a while ago and, as
>> > > part of that effort I've taken to translating the OpenGL API. No,
>> > > I don't mean JUST running the headers through ato-Ada converter
>> > > but actually translating the API into a more Ada-natural form.
...
>> > Having done this a couple of times myself, you should consider the
>> > approach of writing a specialized program that processes the OpenGL
>> > header into a binding. �OpenGL will remain a moving target as
>> > graphic 
> s
>> > hardware continues to evolve. �Compilers will always have their
>> > uniqu 
> e
>> > quirks. �With all this room for variation, it will probably be
>> > easier to maintain a translator than to revise the binding every
>> > time the standard changes or grows.
>>
>> I see what you're saying. The problem is in the specs, the moving
>> target you mentioned, for example the glBegin function ...
> 
> Well, plus the need for backward compatibility.
> 
> Nonetheless, if you have isolated the need to identify glBegin args in
> a table within a translator, so it can spit out the requisite new
> enumeration equivalences, I believe you are ahead of the game.  No one
> is saying the translator will keep working with zero modifications.
> 
> For (an admittedly contrived) example, if the spec introduces a new
> call that accepts anything glBegin will accept plus a few other flags,
> the translator can encode this idea in a new addendum table and an
> algorithm. This is easier and less error prone going forward than
> remembering to update both enumerations in parallel.

I've not tried to use OpenGL myself, but my two cents worth-

I'd prefer the binding not to be as much of a moving target. One
thing you can use is procedure/function overloading as well as 
differently named procedures/functions.  The Ada binding should
have some of the benefit of hindsight, since it is developed
after. So take that advantage and design an API that is "proper".
In other words, make it less of a binding, than a proper Ada
library layer to the OpenGL behind the scenes.

If you extend something, then I think this can be normally done 
without breaking existing APIs. I know there will be exceptions, 
but I'd be real annoyed if I had to re-work my app every time a 
new version of the binding came out.  

This is one of the reasons that my own open sourced projects 
depend upon as few external projects as possible.  I don't like 
having to re-work and debug other user's problems in my software 
by email, inflicted by other dependency projects' [sometimes] 
whimsical changes.

Warren