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-Thread: 103376,e5bfd51af02edca2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news1.google.com!proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!fi.sn.net!newsfeed2.fi.sn.net!feeder2.news.jippii.net!reader1.news.jippii.net!53ab2750!not-for-mail From: Niklas Holsti Organization: Tidorum Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Re-exporting primitive operations of a private type (like "-", and 'min) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: Date: Thu, 03 Nov 2005 11:15:06 +0200 NNTP-Posting-Host: 81.17.205.61 X-Complaints-To: newsmaster@saunalahti.com X-Trace: reader1.news.jippii.net 1131009562 81.17.205.61 (Thu, 03 Nov 2005 11:19:22 EET) NNTP-Posting-Date: Thu, 03 Nov 2005 11:19:22 EET Xref: g2news1.google.com comp.lang.ada:6137 Date: 2005-11-03T11:15:06+02:00 List-Id: Jean-Pierre Rosen wrote: > Niklas Holsti a �crit : > >> With the new feature, the "implementation defined" pseudocode could be >> replaced by real code: >> >> type Storage_Offset is private range <>; -- Not Ada. >> type Storage_Element is private mod <>; -- Not Ada. >> >> The full type declarations would be in the private part of the >> package, as usual. >> >> In such declarations, the "private" keyword is perhaps unnecessary, >> since the presence of the box "<>" shows that the declared type is >> partly hidden. >> >> Does this idea appeal to anyone? >> > I fail to see the benefit. The only thing that would be "hidden" with > such a declaration is the actual value of the bounds. But you could get > them with 'First and 'Last. So, there would be no benefit in pretending > that they are "private". I think there would be a benefit -- it would *force* the clients of this package to use 'First and 'Last, instead of other *not standardized* items, for example some named numbers that may be defined in a particular implementation of this package. But I agree that the advantage in this example is small. Let me explain the context more clearly. You have an Ada program that contains a package A which defines a type A.T, and a package B that uses A.T in some way. For some reason (say, different platforms or different product variants) you have several variants of package A, say A', A" and so on. They all have the Ada name A, but they exist in different source directories, for example. To build a particular version of this program, you select a variant of A and compile it together with B. The variants define the type A.T in different ways; A' may define it as an enumeration, A" as an integer type, etc. You want the same package B to be compatible with all variants of package A, even though the different variants of type A.T differ in detail. Thus, there must be some form of contract or specification that every variant of type A.T must satisfy and which defines how package B can use type A.T. The only way to express such a contract in Ada, now, is to define A.T as (fully) private and provide the necessary operations in package A. But this means that A.T cannot be (visibly) discrete, so it cannot be used as an array index, cannot be used as a discriminant, and cannot be an actual type in generic instantiations where the formal type is more specific than "private". An alternative would be to make package B generic, with a generic formal type standing for A.T, and then instantiate B with whatever variant of A.T is at hand. The definition of the generic parameters of B then define the contract. However, this method is not very practical when there are many packages (B, C, D, ... ZZ) that depend on A.T, and perhaps on other packages with variants. Moreover, it seems like overkill when you know that there will be only a single instantiation of B (and C, D, ... ZZ) in any version of the program. The contract aspect of Ada generics is a good thing, but it is one-sided: it only lets the generic unit specify what it *expects* of a type that it will be given; there is now no similar way to specify what a unit *promises* of a type that it *provides*. One can only define a public type, which usually overspecifies the contract, or a (fully) private type, which has limitations as I said above. My proposal aims for a similar contract aspect for private types, to let the provider of a type specify the type's properties without forcing "the rest of the world" to be defined as generic and parametrized with this type. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .