Types, packages & objects : the good old naming conventions question (without religious ware)
in [ADA]
|
From: Stephen Leake on 30 Oct 2009 06:56 Britt Snodgrass <britt.snodgrass(a)gmail.com> writes: > A short reply to a long post: > > I share your perspective. I work on "real" projects and our > convention is to always use a "_Type" or " _Range" suffix on type and > subtype names. I've also tried "_T" and but didn't like it as much. Interesting. I also use _Type, but I always have. I think in general, abbreviations are discouraged in Ada. I know I generally tolerate longer names in Ada than in C++. > It is still tricky to name type hierarchies (e.g., arrays of > records). I have occasionally used long suffixes like "_Record_Type" > and "_Record_Array_Type" but that can quickly get out of hand. That is not because of _Type; compound types are always harder to name. -- -- Stephe
From: Dmitry A. Kazakov on 31 Oct 2009 05:49 On Fri, 30 Oct 2009 22:30:43 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote: > A quick add-on, before I forget to write it back here - comments > welcome on the assertion : > > A program language terms use the dictionary of natural language. > The natural language has some construct like predicates, adjectives, > verbs (transitive and intransitives ones), an nouns. > > some has one to one match with the concepts used in a program text : > predicates and adjectives, verbs (of both forms). Verb ~ [primitive] operation Predicate/adjective ~ constraint (e.g. "in"), indexing > Remain nouns : they may match either object of types, just because the > natural language does not make this distinction. Indeed, in every day > life, we are not talking using type and class concepts (neither our > ancestors does). No, I think this is wrong. In natural languages there is a distinction between class and instance. In English (I am not native speaker) it is the + uncountable/plural. Other languages have different means. > Thus, the word � cat �, which may either refer to Douda, my pet cat, > or to all Cat being (if I can say it this way). "the cats" In the natural languages the difference is always blurred because classes can be objects, e.g. form super classes. So in the programming languages. The types have operations of they own though rudimentary in Ada (e.g. T'Class, T'Image). You cannot separate the name spaces of them and the objects. (The same it true for subprograms.) Note that generic programming is programming in terms of sets of types. In Ada it is represented by generics and class-wides. Generic programming is considered extremely important paradigm. Here you again come to the case where a type is no more a "proper noun", but just an instance of something more unique. Note also that at the formal level type and object are strictly different. Other programming languages (like C++, Java) have failed here by not distinguishing T and T'Class. Nevertheless for the programmer, conceptually cat is-a cat, and he wants to write programs as-if x of T, were of T'Class. You can never solve this psychological problem. The language shall differentiate object and type, type and class, class and meta class and so on ad infinitum. But the programmer will flow up and down this hierarchy of abstractions choosing his objects and types at each level and names for them. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 31 Oct 2009 07:47 On Sat, 31 Oct 2009 04:30:38 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote: > On 31 oct, 10:49, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> "the cats" > This is a class, not a type > So let's call classes The_Xxxs (with an ending S) > But what about types ? (and instances of a type) Class is a set of types. Type is a set of values. When the cat is an object, the cats is its type. Mammals is the set of types that contain the type cats. The corresponding type can be the mammals, i.e. flatten mammals class. In Ada there is no notation for the class. T'Class is a type, the closure of the class rooted in T, i.e. all values of the members of types derived from T. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Stephen Leake on 31 Oct 2009 08:13 "Jeffrey R. Carter" <spam.jrcarter.not(a)spam.acm.org> writes: > Hibou57 (Yannick Duchêne) wrote: >> >> An example trap (to me at least) : what about a type which would seems >> obviously named Size and a parameter which seems obviously named >> Size ? X would surely not be OK, neither Item. > > If Size is the best name for the parameter, and assuming this a > numeric value, then I'd call the type Size_Value. Why not follow the typical convention, and call the type Size_Type? The type name occurs in fewer places, so it's less noise to modify the type. >> An idea may be to get a more or less close synonymous (like Count... >> not very good) for the parameter for which one may naturally be >> tempted to name Size. But this seems (and is) a work-around, and if >> the word “ work-around ” really legitimately applies on that >> situation, this means there is a trouble (not natural, at least). Why >> the work around will probably applied on the parameter ? Because the >> parameter comes later when the type definition is already introduced >> (in the worst case, it may be tempting to change the type name). This >> latter detail makes us to come to another aspect of the trouble : >> choosing a practicable type name, may requires an amount of prediction >> over what instance names may be. > > I think that you shouldn't be writing anything until you've decided on > the type and its operations, including their parameters. That's not possible, even in principle. You need use cases in order to design a good type and operations. -- -- Stephe
From: Stephen Leake on 31 Oct 2009 08:21
dhenry <tfc.duke(a)gmail.com> writes: > I'm working on a "real" project and the convention we have chosen is > to use suffixes _Type, _Array_Type and _Access: > > type Foo_Type is private; > type Foo_Access is access all Foo_Type; I use Foo_Access_Type for this. > type Foo_Array_Type is array (Positive range <>) of Foo_Type; I use Positive_Array_Foo_Type for this last one. > We use simple rules, so that _Access can be either used for an > "access", and "access all" or an access on a 'Class. If we need both > class-wide access and simple access, we can use _Class_Access but it's > not hard-written in our coding standard rules. This may not be > rigorous, but we're fine with it because it's simple (when we decided > about our coding standards, we didn't want to produce dozens of pages > of rules). > > However there are some drawbacks, like how to name a variable which > should be "message type" (an integer identifying the kind of a > message). We can't use Message_Type, so we use Message_Typ (which is > of type Message_Typ_Type). That's not pretty at all. Yes, this case is a problem. I just use Message_Type_Type, and live with it. Apparantly in Dylan, that would be Message_Type for the object, and <Message_Type> for the type. I like that better. -- -- Stephe |