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,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac5c3bc59168d76 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Subprogram Renaming Date: 1996/04/10 Message-ID: X-Deja-AN: 146814886 references: <316BC3D6.14E7@csehp3.mdc.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-04-10T00:00:00+00:00 List-Id: In article <316BC3D6.14E7@csehp3.mdc.com>, James A. Squire wrote: >On Wed, 10 Apr 1996 00:23:52 GMT, NETNEWS@AMERICAN.EDU wrote: > >> i'll answer: but i want to know how you're going to get me my $64,000... Yes, I would like $64,000, too. Please. ;-) >2. Once again, the real question is: why do I need an explicit body >for j when I can rename k in the spec of q? That has been my question >all along. OK, I finally understand your question. The answer is that you might not want to put this information in the spec. A possible reason is: If you put it in the spec, then re-compilation costs are sometimes *much* higher. So you want to declare j in the spec, but implement it in the body to avoid those recompilation costs. You could, of course, write a body for j that just calls k. The ability to use a renaming as body is just a short-hand for that kind of call-through body. Another possible reason is that the spec where k is declared already 'with'es the spec where j is declared, so you can't put the renaming "j renames k" in the spec because that would cause a circular dependence, which is illegal. Another possible reason: You want the spec to be the same, but you have different bodies, depending on the target system. In one case, the body of j is just a renaming, but in another case, it does more. >> 1) for certain operations, it may be desirable to use a rename >> >> take >> package F is >> subtype Unsigned_int is Interfaces.C.Unsigned_Int; >> function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int; >> end F; >> >> then >> package body F is >> function "+"( Left, Right : Unsigned_Int ) return Unsigned_Int >> renames Interfaces.C."+"; >> end F; >> >> requires a "use F;" clause "use type F.Unsigned_Int"; in comparison not >> having "+" in the spec requires a separate "use" for Interfaces.C; and >> not using the renames requires a body for "+" that is basically extra >> code. > >This example makes NO sense whatsoever to me. How about this instead: > >with Interfaces.C; >package F is > ... > function "+" (Left, Right : Interfaces.C.Unsigned_Int) return > Interfaces.C.Unsigned_Int renames Interfaces.C."+"; > ... >end F; Yes, that works fine. But it means the spec of package F depends on Interfaces.C. Now, of course, Interfaces.C isn't likely to change anytime soon, since it's defined in the RM. But if, instead, this was a user-defined package, then it very well might change, and you very well might want to avoid depending on it from a package spec. >Are you saying that the above is legal in Ada95? So defaults can be >different? (I'm sure this is illegal in Ada83) It is legal, in both Ada 83 and Ada 95, for a renaming to change the defaults. >I never said nor implied that I was expecting some AMAZING NEW >CAPABILITY. I was, however, expecting something more than a shorthand. >Shorthands do not seem to me to be worthy of attention when upgrading a >language. There should be something more to it than that. Sorry to disappoint you, but it really is just a short-hand. In every case where a renaming-as-body is used, you could just as well write a plain old body. The only advantage is that the renaming-as-body is 1 line of code, whereas the plain old body is 4 lines of code -- the verbosity in this case damages readability. Not a big deal. The renaming as body *might* be more efficient, but that's questionable. In GNAT, I believe that a renaming as body and the plain old body will generate identical code. >And that was what I was asking: _What_ situations??? As mentioned >before, in Ada83 I would just write "procedure j(...) renames >Other_Package.k;" in the spec. I hope my answer above is sufficient -- to avoid depending on a spec from a spec, which can cause *huge* recompilation costs in some cases. >Oh, wait a minute. "Type conformance" refers to the base types then? >Then, "Subtype conformance" refers to the actual parameter types being >used? If that's not it, then I must say I am _really_ confused. If >that _is_ it, then as far as I can tell, that describes perfectly what >renaming requires in Ada83, so I must disagree with your last statement. Not sure what you're asking. Type conformance refers to types of parameters, subtype conformance refers to subtypes of parameters. Type conformance is less strict that subtype conformance -- that is, if X and Y are subtype conformant, then they are also type conformant, but not the other way around. You seem to misunderstand the rules for renaming in Ada 83. Subtype conformance is *not* required -- you can declare different subtypes, but they are *ignored*. This is, admittedly, a bit odd. For a renaming-as-declaration (which is the old Ada 83 kind), mode conformance is required, which is less strict than subtype conformance. For a renaming-as-body, subtype conformance is required. Read RM95-8.5.4. - Bob