From: Gautier write-only on
On Jul 11, 4:45 am, BrianG <briang...(a)gmail.com> wrote:

> I don't understand your "rather"; that's exactly my point.  See the
> start of my post.

Sorry, I misunderstood you.

....
> My problem is I can't come up with an obvious
> second name.  Color_F and Color_I (etc) are obvious and simple, so
> maybe that's the best option.

In my opinion it is. It is the closest to the full overloading to
"Color", but avoiding the problem with litterals. Then you can have
also have also "Color" for one of the fp types, same for one of the
integer types.

G.
From: tmoran on
> >>> Procedure Color ( red, green, blue : in double );
> >>> Procedure Color ( red, green, blue : in float );
>
> One problem you'll have is if a user wants to make a call with all
> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler
> won't know which version to use. The best solution I've found (besides
> making users specify a type)

And what's wrong with requiring the user to be unambiguous by specifying
a type? It's unlikely there will be a lot of calls with all literals
(unless generated by some program) so it shouldn't be onerous. And
"Float'(1.0)" is clearer to the person reading the code five years
from now than "Color_F".
From: anon on
In <i1bktn$ucj$1(a)speranza.aioe.org>, tmoran(a)acm.org writes:
>> >>> Procedure Color ( red, green, blue : in double );
>> >>> Procedure Color ( red, green, blue : in float );
>>
>> One problem you'll have is if a user wants to make a call with all
>> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler
>> won't know which version to use. The best solution I've found (besides
>> making users specify a type)
>
>And what's wrong with requiring the user to be unambiguous by specifying
>a type? It's unlikely there will be a lot of calls with all literals
>(unless generated by some program) so it shouldn't be onerous. And
>"Float'(1.0)" is clearer to the person reading the code five years
>from now than "Color_F".


What your are forgetting is the openGL is a specification from the openGL
group ( opengl.org ), it is just like the Ada RM in that respect. For a
program or package, to be classified as openGL it must comply with "openGL
group" openGL specification. Changing any API part nullify the use of
openGL in any part of your system.

So, adding or altering any definitions about the given API must comply with
the openGL specification. Names of the API functions and procedures with
the API defined types are set by this openGL group.

visit
www.opengl.org
for more information on openGL and the "openGL group"

Also, you may find the API specifications predefined with examples in C that
you can alter to Ada there as well.

From: Shark8 on
On Jul 11, 2:46 pm, a...(a)att.net wrote:
> In <i1bktn$uc...(a)speranza.aioe.org>, tmo...(a)acm.org writes:
> >> >>>  Procedure Color    ( red, green, blue : in double );
> >> >>>  Procedure Color    ( red, green, blue : in float );
>
> >> One problem you'll have is if a user wants to make a call with all
> >> literals, i.e. Color(1, 2, 3) or Color(1.0, 2.0, 3.0), the compiler
> >> won't know which version to use.  The best solution I've found (besides
> >> making users specify a type)
>
> >And what's wrong with requiring the user to be unambiguous by specifying
> >a type?  It's unlikely there will be a lot of calls with all literals
> >(unless generated by some program) so it shouldn't be onerous.  And
> >"Float'(1.0)" is clearer to the person reading the code five years
> >from now than "Color_F".
>
> What your are forgetting is the openGL is a specification from the openGL
> group ( opengl.org ), it is just like the Ada RM in that respect.  For a
> program or package, to be classified as openGL it must comply with "openGL
> group" openGL specification.  Changing any API part nullify the use of
> openGL in any part of your system.
>
> So, adding or altering any definitions about the given API must comply with
> the openGL specification. Names of the API functions and procedures with
> the API defined types are set by this openGL group.

That seems, on its face, to contradict BrianG's claim:

> What you have is a way to do it, but that's not what the OP posted. He had
> all procedures named Color, so the user doesn't need to worry about
> implementation. (If I use Color for Double and want to change my program to
> use Float, I have to change the names of all calls, even if I use calls where
> the compiler could determine what I want - and not just calls to Color, many
> routines would have the same issue.) This is also what the OpenGL
> documentation implies should be done in a language like Ada.

But, if he's correct in this earlier post:
> (I've tried starting a similar effort, but never got very far. I was using
> the OpenGL "red book" as a basis; I find it interesting that the OpenGL
> definition recognizes that "some languages like Ada and C++" could implement
> names this way, but every Ada library I've seen follows the C naming scheme.)

Then my renaming (to get rid of the gl- prefix and parameter-type-
postfix) and
overloading them all is a valid OpenGL API.

>
> visitwww.opengl.org
> for more information on openGL and the "openGL group"
>
> Also, you may find the API specifications predefined with examples in C that
> you can alter to Ada there as well.

From: Warren on
John B. Matthews expounded in news:nospam-8BBB96.10151708072010
@news.aioe.org:

> In article
> <68dd0333-f502-4351-9e50-4ec83bddc44e(a)k39g2000yqd.googlegroups.com>,
> Shark8 <onewingedshark(a)gmail.com> wrote:
>
>> Would anyone, other than myself, find such a translation of interest?
>
> I have used AdaOpenGL in the past. Is your project related in any way?
>
> <http://adaopengl.sourceforge.net/>

There is the SDL project: http://www.libsdl.org/libraries.php
available for portable game writing. Something like that in
Ada form would be very useful. This is a big project, to be
sure, but Ada tasking and games seem like a natural fit
to me. I'd be interested in developing some games with this
kind of framework.

Warren