Types, packages & objects : the good old naming conventions question (without religious ware)
in [ADA]
|
From: Stephen Leake on 31 Oct 2009 08:25 "Jeffrey R. Carter" <spam.jrcarter.not(a)spam.acm.org> writes: > dhenry wrote: >> >> I have a question for people not using any suffix like _Type or _T or >> whatever: how do you name your access types? Do you allow here to use >> a suffix? > > The objection is not to suffices; it's to suffices that add no value, > which is true of _T[ype]. I personally like _Ptr for access types; on > my current project the guideline is to use _Handle if there isn't a > better name. We happen to think _Type adds a lot of value; it saves effort during writing and reading code. I agree it doesn't add any intrisic meaning to the word, but that's not the only kind of value that's important. -- -- Stephe
From: Stephen Leake on 31 Oct 2009 08:26 Stephen Leake <stephen_leake(a)stephe-leake.org> writes: > 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++. Another point; _T could easily be part of an object name (short for time, or top, or a math subscript of some sort). _Type is clearer. -- -- Stephe
From: Dmitry A. Kazakov on 31 Oct 2009 09:36 On Sat, 31 Oct 2009 05:38:32 -0700 (PDT), Hibou57 (Yannick Duchêne) wrote: > On 31 oct, 12:47, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> 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. > You are right, this is not a class. > But the type may rather be seen as an abstraction of each individual > instance (or as a representation of all the possible instances, thus > the set, but not as a set of instances). The type, provide the way to > create an instance, it may be used to create a set of value, but it is > not a set of value (I know you use type right, I'm just trying to make > terms clear). Well, the set of all values of a type is equivalent to the type itself. It would make little sense to distinguish them. That is formally. Practically there is an aspect of constructiveness. We cannot enumerate all integers, so we name them as Integer in order refer the set of, without constructing it in the body. Any set of values is a type but it is incomputable to decide of which type. In other words since structural equivalence does not work we need type names. And even if the type T is "new Integer", indeed an integer, we do not recognize that, and treat T and Integer distinct types. That is another reason why we are short in type names. > So let say now your « The Cats » is a type, and finally there is > something which mark it, so this goes in the way of a mark to state a > name is used a a type. “ The ” and the plural, may be seen as > equivalent to the “ _Type ” This is the instance-to-set way, but there is reverse approach: set-to-instance. E.g. "of x", the possessive case "x's", the article "a x". Natural languages are damn flexible. Some people like: procedure Skin (Cat : A_Cat); others do procedure Skin (A_Cat : Cat); (:-)) I don't like either. Sometimes I do: procedure Skin (Victim : Cat); Many do procedure Skin (Object : Cat); Some natural languages apply cases to indicate objects: procedure Skin (Objet : Cat; Tool : Knife; Customer : Butcher); (accusative, instrumental, dative cases). Interestingly that cases represent some kind of types (roles) of objects. >> 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. > This do the job, isn't it ? And this is true that a type — which may > be, at least potentially — the subject of any number of derivations, > at least potentially stands for a class, even it is not actually > derived. So there is no trouble to get the class rooted at a type from > a type attribute. There is no need for an explicit declaration of a > class, because the class associated to a tagged type, always exist, > that's the concept, and does not need any declaration (the subtype is > there, if a declaration is needed or wished). No, it is rather because T in T'Class is decidable. But it is not necessarily always so. Already with generics people run straight into troubles passing T'Class for a plain formal type and wondering why no dispatch happen. Again the question is how and if "member of" is computable/obvious. Once types might become a more first-class citizens, or the structure of classes more complicated T'Class might cease to work well. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Stephen Leake on 1 Nov 2009 03:15 "Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)yahoo.fr> writes: > 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). This is an interesting point. There are some cases of English nouns that are by definition groups; a gaggle of geese, a pride of lions. But there is no general convention for this. I don't know enough other languages to say whether this is a universal truth about human languages. > Is this mark very important to be standardized ? Maybe for Ada 83; it is too late now. -- -- Stephe
From: Stephen Leake on 1 Nov 2009 03:21
"Hibou57 (Yannick Duch�ne)" <yannick_duchene(a)yahoo.fr> writes: > On 31 oct, 13:21, Stephen Leake <stephen_le...(a)stephe-leake.org> > wrote: >> > type Foo_Type is private; >> > type Foo_Access is access all Foo_Type; >> >> I use Foo_Access_Type for this. > > What's your reason to use Foo_Access_Type instead of Foo_Access ? Just so the convention "all types end in _Type" is universal. That helps when building tools that generate code, like Auto_Text_IO. I'm also more rigid than a lot of people when it comes to rules. > Is that because of objects named Foo_Access ? I rarely do this; I use "Foo" for either a Foo_type object or a Foo_Access_Type object, unless I need both in the same scope. Even then, I usually use _Ptr, not _Access. But it is a valid reason for Foo_Access_Type. -- -- Stephe |