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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/09/04 Message-ID: <35F0E019.DAAE4635@sprintmail.com> X-Deja-AN: 388091889 Content-Transfer-Encoding: 7bit References: <6qfp80$p0u$1@nnrp1.dejanews.com> <35CD0A8E.21D64380@sprintmail.com> <35CEBAAF.B9B82820@sprintmail.com> X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: Fri Sep 4 23:54:48 1998 Organization: EarthLink Network, Inc. Mime-Version: 1.0 Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1998-09-04T00:00:00+00:00 List-Id: Matthew Heaney wrote: > > "John G. Volan" writes: > > > With all these various cases, isn't your scheme really ad hoc? > > I wouldn't describe what I do as ad hoc. If you've read the code in my > other posts, I'm sure you wouldn't describe it as ad hoc either. You > might even be tempted to say it's sorta elegent. I did read your posts, and I saw your code examples. To me, personally, your style strikes me as ad-hoc. I've already given rationales for why I feel that way, a couple of times now. I guess we'll just have to agree to disagree. > > If you claim it is not ad hoc, can you articulate a finite number of > > rules that cover all situations (or at least a sufficient majority of > > them)? > > Hmmm. Let's see. > > 1) Name the (abstract) root of a hierarchy of tagged types Root_. > > One exception (oops, an exception already, on the first bullet!) And from that one would conclude ... what? ;-) > is if > there's already a good two-part name from the problem domain, use that > instead of Root_. The classic example is Bank_Account, from which > Checking_Account and Savings_Account derive. "Bank_Account" is a good term because it comes straight from the terminology of the problem domain. "Root_Account" is bad because it embeds an implementation detail (the fact that this type happens to be at the root of an inheritance hierarchy) as part of a name. If that design decision should change and a different implementation scheme were applied, the name would suddenly become inappropriate -- even though the entity it denoted was still the same conceptual notion from the problem domain. For instance, suppose you started with "Bank_Account" as the root of your hierarchy, but later expanded the application to include other kinds of accounts, such as "Mutual_Fund_Account", etc. You might have a need for an even more general notion of "Account" that would cover all kinds of accounts. This "Account" type would become the new root of the hierarchy, and "Bank_Account" as well as "Mutual_Fund_Account", etc., would now inherit from it. But if all along you'd been using the name "Root_Account" instead of "Bank_Account", you suddenly have to change the name to something else. Furthermore, who says Checking_Account and Savings_Account aren't themselves the roots of their own sub-hierarchies? Here, you would probably say that "Root_" is unnecessary because these types already have expendable adjective prefixes you can drop. I would say "Root_" was unnecessary in the first place. > 2) Name the type _Type to indicate static polymorphism, ie > > generic > ... > package Stacks_Unbounded is > > type Stack_Type is private; > > generic > ... > package Stacks_Bounded is > > type Stack_Type is private; At one point in this discussion I think I might have grokked your notion of "static polymorphism", but it's gone completely from my head now, and the thread has evaporated. Is it that these generic templates provide alternate implementations of essentially the same interface, but without having a common parent type that they both inherit from? Honestly, I can't understand your rationale for why this property in particular would make "_Type" a good prefix here, but not for other types. > 3) Name scalar types using the units in the name, ie > > type Heading_In_Degrees is ...; This is worth another post. > 4) If you often refer to an acronym, then use expanded name as the type, > > SOI : Signal_Of_Interest; > > PDW : Pulse_Descriptor_Word; See my previous post. > 5) Name arrays _Array, and name the array instance the plural: > > type Stack_Item_Array is > array (Positive range <>) of Stack_Item; > > Items : Stack_Item_Array; Here's how I might handle this: generic type Item_Type is private; package Stacks_Bounded is type Stack_Type (Capacity : Positive) is ... private; ... private type Items_Type is array (Positive range <>) of Item_Type; type Stack_Type (Capacity : Positive) is ... record Top : Natural := 0; Items : Items_Type; end record; end Stacks_Bounded; > 6) Never ever name a scalar type as a plural > > type Tuner_Ids is range 1 .. 4; -- you're a bad boy > I makes zero sense to see this > > Id : Tuner_Ids; Well, this is one restriction I can agree on! type Tuner_Id_Type is range 1 .. 4; -- no plurals! As I've said before, I don't really object to dropping a prefix when the context will let you get away with it: Id : Tuner_Id_Type; But my point is that you cannot in general rely on that. Sooner or later you'll run into a context where the prefix has to be put back: Tuner_Id : Tuner_Id_Type; Amplifier_Id : Amplifier_Id_Type; -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE