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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8d5151b6052512f7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-08 07:18:21 PST From: "Luke Guest" Newsgroups: comp.lang.ada References: <404c7e53.0@entanet> Subject: Re: Overloading procedures with Float and Long_Float types Date: Mon, 8 Mar 2004 15:18:15 -0000 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 NNTP-Posting-Host: 195.74.122.227 Message-ID: <404c8f63.0@entanet> X-Trace: 8 Mar 2004 15:21:07 GMT, 195.74.122.227 Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!priapus.visi.com!orange.octanews.net!news-out.visi.com!petbe.visi.com!news.octanews.net!upp1.onvoy!onvoy.com!newsfeed.yul.equant.net!newsfeed.uk.prserv.net!prserv.net!news.freedom2surf.net!entanet!195.74.122.227 Xref: archiver1.google.com comp.lang.ada:6145 Date: 2004-03-08T15:18:15+00:00 List-Id: > GLfloat (1.0) or better GLfloat'(1.0) is exactly that hint. It tells > that the numeric literal 1.0 has to be converted to (the first case), > or expected to be of (the second case) the designated type. How could > it be otherwise? Carefully observe that the type of 1.0 is neither > Float nor Long_Float. It is Universal_Real. (see ARM 2.4) Fair enough. > >Basically, it just seems to be wasting a good opportunity for overloading > >here. > > Surely not. > > Generally, oveloading is not a very brilliant idea in the case like > yours. Overloading is a way to make different things look similar. > (polymorphic as it called in OO) And what is a difference between > Float and Long_Float? The length of mantissa? This is a pure > implementation detal, which has to be hidden. IMO the actual problem > here is bad design. If you are witting an OpenGL application you have > to choose which precision is suitable for this concrete application. > If you are designing bindings to OpenGL, then it is better to place > float and double things in two different [paths of] packages. And > finally, calling subroutines with "magic" numeric literals is the most > obscure way of programming. Hmmm, this will also mean, that glVertex[234][is] wil cause problems here (integer vertices). I also don't think it makes sense design wise to move them into separate packages for int, short, float, double, as some apps would like to mix them. Maybe a good compromise here would be to either: 1) Not use overloading, and postfix the procedure call with the type, a la OpenGL [FD], or 2) Move into separate packages and overload on number of parameters, a la OpenGL [234]. Thanks, Luke.