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: Brian Rogoff Subject: Re: Distinguishing type names from other identifiers Date: 1998/01/28 Message-ID: #1/1 X-Deja-AN: 320012628 References: <01bd2078$a449b460$41fd82c1@xhv46.dial.pipex.com> <6v0LMGAjwIw0Ews0@dowie-cs.demon.co.uk> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 886008355 21902 bpr 206.184.139.132 Newsgroups: comp.lang.ada Date: 1998-01-28T00:00:00+00:00 List-Id: On Tue, 27 Jan 1998, Matthew Heaney wrote: > In article , > Brian Rogoff wrote: > >and I never have collisions between type and variable names. In generic > >code, choosing specific names (as Matthew Heaney suggested, I think) > >becomes much harder, the code is generic after all. This convention also > >makes it easy to write source analysis tools which get type names by > >simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is > >redundant, but then so are comments, readable names, the distinction in > >Ada between functions and procedures ;-), ... > > In practice, names for generic types aren't any harder either. The > convention I use is something like > > generic > type Stack_Item is private; > with function "=" (L, R : Stack_Item) return Boolean is <>; > package Stacks is > > type Root_Stack is abstract tagged null record; > > function Top (Stack : Root_Stack) return Stack_Item; > ... > end Stacks; That's a very nice convention, but as you acknowledge below, its really no different from _Type, since you add a redundant qualifier "Stack_" to the name. > Here's one case where I'd concede that the _Type convention makes sense, > because you want to emphasize the inchoate character of the formal type. > But I pretty much use the adjective+noun convention for formal types too, > for consistency. That seems reasonable to me. I'd have no problem adopting this, even if I prefer "_Type" ;-). I would also use _Func, _Proc, for access to function and procedure, and _Class (for classwide types); I think that's about it. In Beidler's Scranton data structure suite a far more elaborate naming scheme is used, but its too much for my tastes. GNAT code is more like yours, except less verbose, i.e., more abbreviations. I can live with that, though obviously I prefer the style I'm describing. > 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? > Boy oh boy, I really, really wish we had access constant parameters and > discriminants. Oh well. Yeah well. I wish hard for out mode function params, but it ain't gonna happen. Its really nice to have a language thats not changing all the time too! When the next Ada 200X thread starts, we'll all have a chance. -- Brian