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,4200259190b16e16 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-28 05:13:30 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Visibility problems with package instantiations..... Date: Fri, 28 Nov 2003 14:17:03 +0100 Message-ID: References: <95234e08.0311270742.631b1228@posting.google.com> <349csv0udb5k0kuk0q99d7tm7fh5leuefu@4ax.com> <95234e08.0311280323.7a5bb870@posting.google.com> NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1070025208 65910911 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:3024 Date: 2003-11-28T14:17:03+01:00 List-Id: On 28 Nov 2003 03:23:50 -0800, petter.fryklund@atero.se (Petter Fryklund) wrote: >Now taking this further. If Gen_3 only needs a few of the parameters >of the instantiation of Inst_2 to be correct or known, wouldn't it be >nice to be able to do: > >with Gen_0; >with Gen_1; -- with 200 other parameters .... >generic > with package Inst_0 is new Gen_0 (<>); > with package Inst_1 is new Gen_1 (Inst_0 => Inst_0, others => >(<>)); >package Gen_2 is > ..... Well I am not a fan of generics. Any implementation based on generics is suspicious to my taste. That's aside. Returning to your question, a package with 200 parameters is even more suspicious from design point of view, than the fact of being generic. However, there is another way to "inherit" from packages. Ada offers child packages. For example you could make Gen_1 a child of Gen_0 to inherit all its generic parameters. To your proposal. It goes the direction of making generic formal parameter profiles to closer resemble the parameter profiles of subprograms. That's not easy. If we dig it a bit deeper, we will discover that for example: procedure Foo (X : Integer; X : Float); -- Clearly illegal but generic with function X return Integer; with function X return Float; procedure Foo; -- This is fine! So any proposal concerning named associations of the generic parameters should somehow deal with this nasty problem (at least). BTW, true procedural types could help here, because then, one could use qualified expressions. Alas, Ada misses them. -- Regards, Dmitry Kazakov http://www.dmitry-kazakov.de