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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2afac1a4161c7f35 X-Google-Attributes: gid103376,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: Distinguishing type names from other identifiers Date: 1998/01/28 Message-ID: #1/1 X-Deja-AN: 320148642 Content-Transfer-Encoding: 8bit References: <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com> <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1998-01-28T00:00:00+00:00 List-Id: In article , Brian Rogoff wrote: >> Another example is importing an active iterator as a generic formal type: >> >> generic >> Max_Depth : in Positive; >> package Stacks.Bounded is >> >> type Bounded_Stack is new Root_Stack with private; >> ... >> generic >> type Source_Stack is new Root_Stack with private; >> >> type Source_Stack_Iterator (Stack : access Source_Stack'Class) is >> new Root_Stack_Iterator with private; >> >> procedure Generic_Copy >> (From : access Source_Stack'Class; >> To : in out Bounded_Stack); >> >> end Stacks.Bounded; > >This is also OK, but I still don't see why you find the redundant _Type >to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like >_Stack worse, since qualified package names already have that information. >What's your thinking on this? I always use adjective+noun. A tagged type hierarchy always has this convention: each derivation has a different adjective, but the noun is the same. I never use package qualification to get the "real" name, because the real name is always the name of the type. A package is just a namespace - it is not a type. The Root_ convention comes out the RM, and I have adopted it for consistency with that document. The adjective+noun style also comes out of the RM: it's what is used for types Bounded_String and Unbounded_String. So you'd have something like type Root_Stack is abstract tagged null record; type Bounded_Stack is new Root_Stack with private; type Unbounded_Stack is new Root_Stack with private; type AVL_Set is new Root_Set with private; type Prioritized_Queue is new Root_Queue with private; In my generic example, I chose Source_Stack as the name because some stack type named _Stack that inherits from Root_Stack is the source of the data for the copy. I suppose you could argue that _Stack is redundant, but 1) I always use adjective+noun consistently, and 2) the type name stands alone, and doesn't require package name qualification. Consider another example: package Bank_Accounts is type Bank_Account is abstract tagged null record; ... end Bank_Accounts; package Bank_Accounts.Checking is type Checking_Account is new Bank_Account with private; ... end Bank_Accounts.Checking; package Bank_Accounts.Savings is type Savings_Account is new Bank_Account with private; ... end Bank_Accounts.Savings; You get the idea. Some guys name their abstract data type "Object" or "Instance," but this is a horrible convention because it confuses the concepts of type and module. Some Ada programmers actually think that a class in C++ or Eiffel maps to an Ada package! A sure sign of confusion. A class in C++ is the equivalent of an Ada tagged type. Yes, I know that in other languages a class does double-duty as a module and type, but in Ada they are orthogonal language features. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271