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,8bb81cae35ee307f X-Google-Attributes: gid103376,public From: John G. Volan Subject: Re: Package Parts [was: Ada GC and a bunch of other stuff] Date: 1996/02/22 Message-ID: <4gh2da$ffb@dayuc.dayton.saic.com> X-Deja-AN: 140697830 distribution: world references: content-type: text/plain; charset=ISO-8859-1 x-xxmessage-id: organization: Science Applications International Corp. (SAIC) mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-02-22T00:00:00+00:00 List-Id: In article , Gene Ouye wrote: >:John Volan wrote: >:> (6) Here's a purely notational issue: Personally, I dislike the notion >:> of identifying a package-part by a number. Part-numbers wouldn't convey >:> any idea of the purpose that a programmer had in mind for each >:> package-part. I think using some kind of identifier would be a lot >:> better, in terms of readability, self-documentation, etc. >: >:Actually, it's relatively simple to convey the purpose of each part of >:the package. Norm's proposal doesn't say the part numbers have to be >:numeric literals, it says they're static universal integer expressions >:(something I've seen too much of in another thread :-). Assuming that >:context clauses go in the same place that they do in Ada 95, all you >:need to do is create a program configuration package (not to be confused >:with a configuration pragma, although they may be applicable ;-). In >:the configuration package, you can define named numbers that will convey >:both the purpose of the package part and the sequencing of the parts. >: >:> Of course, one of the things that Norman's syntax achieves is that it >:> imposes a definite sequential order on the parts of a package. >:> Furthermore, each package-part declares not only its own numeric >:> position, but also the total number of package-parts in the sequence. >:> (Presumably, all the package-parts would have to agree on this total.) >:> Thus, within any package-part, it's always possible to know how many parts >:> precede it and how many follow it. >: >:If you use named numbers for the part numbers, a cursory examination of >:the package part source file wouldn't necessarily show how many parts >:precede or follow the part. You'd have to look in the configuration >:package. That would make it a little more difficult to find out how many >:parts there were, but it would make it simple to change the number of >:parts. Of course, at compile time the package part will know how many >:parts could potentially precede and/or follow it (it couldn't know for >:sure unless there is some kind of requirement that there must be a part >:corresponding to each number in the part number range). Yes, I was assuming that there would be a consistency rule that said that there would actually have to be a compilation unit in the library for every part-name in the indicated set of part-names (whether that set is implied by a total count as in Norman's syntax, or explicitly enumerated as in my proposal). >:This would also >:make it easier to reorder the parts, although I would expect that to be >:infrequent due to problems with the arbitrary rearranging of the >:declarative region. However, if there were some problems, they would be >:found at compile time. >: >:> To achieve the same affects with identifiers instead of numbers, we'd >:> need to be able to enumerate the identifiers of all the parts of a >:> package somehow. The order in which the identifiers appeared in this >:> enumeration would determine the sequential order of the package-parts. >:> The position of a package-part's identifier within the enumeration >:> would determine the package-part's position within the sequence. >: >:I think named numbers achieves this, see the example. >: >: >: package My_Part_IDs is >: GUI : constant := 1; >: Business_Logic : constant := GUI + 1; >: DBMS : constant := Business_Logic + 1; >: >: Total_Parts : constant := DBMS; >: end My_Part_IDs; >: >: with My_Part_IDs; use My_Part_IDs; >: package My_Package (Business_Logic of Total_Parts) is >: ... >: end My_Package; For that matter, if we accept this notion of declaring the part-names in a prior configuration package, then there's no particular reason why the part names need to be named numbers. I have suggested that the part-names could be "enumerated" somehow. Although I didn't necessarily mean for this "enumeration" to be an enumerated _type_ per se, this configuration package idea would in fact allow us to use an actual enumerated type for the set of part names. Let's try out a hybrid of the syntax from Norman Cohen's proposal and the syntax from my counter-proposal, combine it with this notion of a configuration package, and see what we get: package Stack_Configuration is type Parts is (Interface, Completion); end Stack_Configuration; with Stack_Configuration; use Stack_Configuration; package Stack (Interface in Parts) is ... end Stack (Interface in Parts); with Stack_Configuration; use Stack_Configuration; package Stack (Completion in Parts) is ... end Stack (Completion in Parts); package body Stack is ... end Stack; Like Norman's proposal, a part-id is placed in parentheses along with an indication of the total set of part-ids from which it is taken. But here the part-id is an enumeration literal and the set of part-ids is indicated by the name of a previously-declared enumerated _type_. (Thus the use of the keyword "in" conveying a sense of membership in a set, rather than the keyword "of".) (Also, as in my counter-proposal, only the package spec is split into parts; the package body keeps its distinct syntax as in Ada 95.) However, regardless of whether the part-names are enumeration literals or named numbers, there's something a bit unsatisfying about having to declare a separate configuration package first just to house the part-names, before you can actually declare the target package in its various parts. I think it would be better if a package could remain an autonomous, self-contained entity, regardless of whether it happens to be decomposed into multiple parts or not. What happens at the client level? Before a client can "with" a specific package part, it seems that it would also have to "with" (and "use") the configuration package: with Stack_Configuration; use Stack_Configuration; with Stack (Interface in Parts); package Partial_Client is ... Again, there's something unsatisfying about having to bring in this configuration package before you can even mention the package-part you want to "with". >:Of course, you could also make the configuration package be the >:parent of the parts, and define the part IDs there. That might help alleviate some of the awkwardness, but I'd still prefer it if a package-with-parts could be as "idempotent" as any other package. That's why I'd favor some kind of special syntax that would allow a package to enumerate its parts, rather than using some kind of conventional Ada declaration (like an enumerated type) that requires a prior declarative region to be declared in. With regard to possibly needing to re-order the package parts: I think using an enumeration would actually be easier than a series of named numbers. All you'd have to do would be to change the order of the enumeration literals in the type declaration, whereas in a cascade of named numbers declarations not only do you have to change the order of the declarations, but you also have to make sure that each one is actually incremented from its new predecessor -- that might be quite error-prone. Another reason for favoring enumerations over named numbers is the impact part names would have on Ada library management. If package parts were identified in the library by part-numbers, then re-arranging the parts would force you to move all the parts to different part-numbers. (In terms of GNAT's source-file-based library management scheme, the first package part would have to go in, say, a file called *.ad1, the second in file *.ad2, and so forth, regardless of the names we happen associate with those numbers; changing the order would require moving the files to different names.) On the other hand, if package parts were stored in the library under part-names that were true identifier literals, presumably those literals wouldn't have to change if we re-ordered the parts. The only thing that would change would be the positional order the compiler associated with each literal. (In GNAT terms, we could, for instance, keep parts A and B of package P in files named, let's say, "p=a.ads" and "p=b.ads". If we happened to switch the order of the parts so that B came before A, we'd need to edit the enumeration declaration, but we wouldn't need to rename the files.) ------------------------------------------------------------------------ Me : Person := (Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Employer => "Science Applications International Corporation (SAIC)", Affiliation => "Enthusiastic member of Team-Ada!", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Shameless_Commercial_Plug => "RADSIM: Low-cost, real-time radar simulation *in Ada* " & "Check out: http://www.dayton.saic.com/aso_homepage.html ", Humorous_Language_Lawyerly_Disclaimer => "These opinions are undefined by my company, so any use of them" & "would be erroneous ... or is that a bounded error now? :-) " ); ------------------------------------------------------------------------