Types, packages & objects : the good old naming conventions question (without religious ware)
in [ADA]
|
Prev: Attribute denoting a subprogram : no named parameter associations allowed
Next: Question on array of strings
From: Randy Brukardt on 2 Nov 2009 16:47 "Stephen Leake" <stephen_leake(a)stephe-leake.org> wrote in message news:uskcz6ahs.fsf(a)stephe-leake.org... .... > Here are the similar definitions from > Ada.Containers.Indefinite_Doubly_Linked_Lists. I hope you won't start > arguing that is a bad abstraction. > > package Ada.Containers.Indefinite_Doubly_Linked_Lists is > > type List is tagged private; > > generic > with function "<" (Left, Right : Element_Type) return Boolean is <>; > package Generic_Sorting is > > function Is_Sorted (Container : List) return Boolean; > end Generic_Sorting; > end Ada.Containers.Indefinite_Doubly_Linked_Lists; > > Note that it uses _Type for Element! If anyone cares, that's because we used a form of Stephen's rules for naming these. In this case, we determined that the best name ("Element") should be reserved for the operation, as the operation will likely be used many times, while the formal type name is hardly ever written in client code (just as a name in the instance) -- note this ties into one of the previous threads here. We considered using longer names for the operation like "Get_Element", "Read_Element", etc., but those just made the name longer without adding enough additional information. After all, an important rule is to make names long enough to capture all of the critical information, but no longer (because there is a point where names get too long for readability). Randy.
From: Hibou57 (Yannick Duchêne) on 4 Nov 2009 10:44 May be a step to help to go forward : I remember that I oftenly saw, in some Windows API documentations, something which I feel nice : some type declarations were coming with a suggested prefix to be used as a tag indicating the type in the purpose of the Hungarian notation. I'm not thinking about mapping this exact thing, but it make me thing about a similar idea. This may be cool, to provide a small list of suggested names for concrete instance of generic packages, object instances of a type, derived type name, etc, when applicable. In a whole, the idea to provide naming hints beside declarations, whenever a declaration is subject to later instantiations or later derivations. This does not solve the question exposed by this topic, but this may be a tool to use in this area.
From: Stephen Leake on 4 Nov 2009 19:33 "Peter C. Chapin" <pcc482719(a)gmail.com> writes: > Stephen Leake <stephen_leake(a)stephe-leake.org> wrote in > news:u4ope4pqa.fsf(a)stephe-leake.org: > >> Yes, but reading is also important. The _Type suffix is essentially >> noise when reading; it's only there for the compiler, not the human. >> So you want to read it as few times as possible, as well as write it >> as few times as possible. > > This seems backwards to me. I could use a type name such as X72efY9 for all > the compiler cares. The _Type suffix is most definitely for the human. It > says, "Hey! This is the name of a type so keep that in mind when looking at > this code." Well, you can read it that way. But the original reason the _Type convention got started (at least, as far as I'm concerned) is to solve the problem of overlapping object and type namespaces. This is illegal: procedure (List : in list); So we have to add noise to either the object or the type, to keep the compiler happy. That's all there is to it. > In the past I used _Type as a suffix for all of my types. However, there > are times when that doesn't seem to fit. After all the standard types don't > (usually) use a _Type suffix (Character, Integer, Positive, Vector, etc). The standard is Just Wrong. But we have to live with it. -- -- Stephe
From: Stephen Leake on 4 Nov 2009 19:39 Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes: > Stephen Leake schrieb: > >> Op_1 (onto => list, element => object_1); >> Op_2 (from => list, element => object_2); >> Op_3 (container => list, element => object_3); >> >> It's much easier if it's always "list => list". > > Well, ease as an excuse... I find it much easier to write > C++, fast; C++ at some level is much easier and more > permissive---easier until there is some odd crash > and you look through the large combinatorial array of > generic library names(!) in a long diagnostic message... I meant easier in all senses; fewer compiler errors, fewer real errors, less development time. > I think the ease argument will be interesting if it becomes > clear what the Op_N stand for, respectively. If you start asking about what they stand for, you've missed the point. I should not have to waste time thinking about that; I know they come from the list package, so the type is List_Type, and the parameter name is List. Now I can think about the _other_ parameters. > Cf. valid Eiffel: > > local > string: STRING > do > ... -- more uses of string and STRING. Or StrINg. That is the argument both for and against case sensitivity. -- -- Stephe
From: Dmitry A. Kazakov on 5 Nov 2009 03:37
On Wed, 04 Nov 2009 19:33:58 -0500, Stephen Leake wrote: > "Peter C. Chapin" <pcc482719(a)gmail.com> writes: > >> In the past I used _Type as a suffix for all of my types. However, there >> are times when that doesn't seem to fit. After all the standard types don't >> (usually) use a _Type suffix (Character, Integer, Positive, Vector, etc). > > The standard is Just Wrong. But we have to live with it. Huh, it is not too late to introduce: package Standard is ... subtype Integer_Type is Integer; end Standard; But Know what? "subtype" looks awfully wrong! Should not it be "subtype_type"? What about type_type String_Type is array_type (Integer_Type range <>) of Character_Type; (:-)) Consider it this way, if _Type is felt appropriate then that is semantically equivalent to types having a separate name space. The latter could be introduced in Ada at any time, being fully backward compatible. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |