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,FREEMAIL_FROM autolearn=ham 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,CP1252 Path: g2news2.google.com!postnews.google.com!37g2000yqm.googlegroups.com!not-for-mail From: =?ISO-8859-1?Q?Hibou57_=28Yannick_Duch=EAne=29?= Newsgroups: comp.lang.ada Subject: Re: Generic package parameters not externally visible : what's the rational ? Date: Thu, 5 Nov 2009 02:38:46 -0800 (PST) Organization: http://groups.google.com Message-ID: <67b00f8a-3d12-48c9-ad5a-34980cf82e08@37g2000yqm.googlegroups.com> 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> <1ueb9d0h9nmm3$.11lt1wv42yxvt.dlg@40tude.net> NNTP-Posting-Host: 77.198.58.176 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1257417526 7780 127.0.0.1 (5 Nov 2009 10:38:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 5 Nov 2009 10:38:46 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 37g2000yqm.googlegroups.com; posting-host=77.198.58.176; posting-account=vrfdLAoAAAAauX_3XwyXEwXCWN3A1l8D User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; fr),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8993 Date: 2009-11-05T02:38:46-08:00 List-Id: On 3 nov, 10:59, "Dmitry A. Kazakov" wrote: > > 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... I was not really sure about the meaning of =93 mess out =94 (the term you used), now I suppose this may mean =93 real mess =94, and here is why. I see at least three productive enough mess seeds with generic child hierarchy (from the less to the most nasty) 1) The implicit with which comes with all child packages, generic or not (I had never really enjoyed this implicit With). 2) The miss-match between the generic Withed path and the actual instance matching path 3) The naming nightmare which comes while creating the instance hierarchy With more details : 1) Dependencies are clearly explicit with classic packages, this is no more the case with child packages. I know this is the same with non- generic, but this is not really welcome to me (I sometime dream about child packages hierarchy which would require explicit With). 2) Let A, a generic package, B, a generic child of A, C, an instance of A, then instantiating C.B requires to With A.B. I understand why it is this way (although this could have been another way too), but an A.B whose A actually and implicitly match C, does not help to be clear. 3) The one I really do not like : with same packages as in #2, instantiating A.B as a child of C, requires to use a new name which cannot be B, and if the name B is the most natural one in the context of A, this mostly mean this would be the same in the context of C, thus the naming nightmare. For the purpose of the comment which will follows right after, let call it D. To reword what you were saying, there is indeed three hierarchies and not two : the source generic hierarchy (like A.B), the instance hierarchy (like C.D) and beside this instance hierarchy, another implicit generic hierarchy (like C.B), and this is hard to deal with. Yes, now I'm sure you were really talking about mess. #3 may be solved using a standard prefix for all generics, like Generic_, but I do not like it, because this easily ends in too much long paths. Now I'm seeking for a more clever way to easily handle this three-hierarchies structure. This would not Solve #2 any way. (Hope I was Ok to post these comments here)