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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,da85d9aaf769b16a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Generic package parameters not externally visible : what's the rational ? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <10eygvuzeit9g.xwy2wanxoxgf$.dlg@40tude.net> <1kf8mo4r9lqxg.1tdhqe6femt9m.dlg@40tude.net> <1r8etjwa9k46n.3pyj04jn686o$.dlg@40tude.net> <1trjf9wxhbsqb$.14uxfibpc7k8x$.dlg@40tude.net> <19ee7f4e-513a-4caf-9822-4610ff2155b2@m16g2000yqc.googlegroups.com> Date: Tue, 3 Nov 2009 10:59:55 +0100 Message-ID: <1ueb9d0h9nmm3$.11lt1wv42yxvt.dlg@40tude.net> NNTP-Posting-Date: 03 Nov 2009 10:59:55 CET NNTP-Posting-Host: 7fab47ec.newsspool1.arcor-online.net X-Trace: DXC=]o_cNa7YVKim7>ihJR;B_cic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbmGkRO8M>Shk[6LHn;2LCVn7enW;^6ZC`dIXm65S@:3>o6;Ob11Sjm2d X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8952 X-Original-Bytes: 3430 Date: 2009-11-03T10:59:55+01:00 List-Id: On Tue, 3 Nov 2009 00:25:24 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote: > On 31 oct, 10:14, "Dmitry A. Kazakov" > wrote: >> Note that a generic child package can use formals of its parent. That is >> the case why your proposal about visibility is so important in my eyes. It >> is an *obvious* language bug. > > A step to the side, still related to your comment ... > > Although related by derivation, my packages were all along each others > (I'm experimenting, so I try many things before I choose and know > why). I've started to rework all package, to use child package when > possible. > > It seems it saves a lot to do so : shared generic parameters, so less > generic parameters needed for instantiation. There is also a competitive way of "generic interface package", so to say. That is when generic parameters are passed with another generic package rather than directly. E.g.: generic type T is private; with function "+" (Left, Right : T) return T; package Generic_Interface is -- No own declarations, the package promotes its formal parameters -- to other packages end Generic_Interface; with Generic_Interface; generic with package Parameters is new Generic_Interface (<>); package P is -- Here we can define some further operations on Parameters.T and -- other types based on Parameters.T end P; > Generic package hierarchy is nicer than I previously supposed Yes, but beware that there are *three* hierarchies: 1. one of the generic packages 2. of the instances of generic packages (you can instantiate a generic child of generic A as a non-generic child of non-generic B) 3. of nested packages (you can instantiate within a package) A creative use of 1-3 may create a perfect mess out of your program... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de