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: Stephen Leake on 6 Nov 2009 05:26 "Vincent Marciante" <vmarciante(a)decilog.com> writes: > "Stephen Leake" <stephen_leake(a)stephe-leake.org> wrote in message > news:u1vkdrert.fsf(a)stephe-leake.org... >> 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. > > That is not necessary: > > package sdgfkjasf is -- or whayever > > type List is ... > > procedure jsdfks (List : sdgfkjasf.List); > > ... That's the first time I've seen that suggestion. It's very interesting. The package name has to show up every time the type is paired with an object of the same name. But in other situations, the package name can be left off. So this ends up being less noise than appending _Type everywhere. Just to be pedantic, it _is_ adding noise. It's just a different form of noise than _Type. I'll have to try it in a semi-real project. I've been using _Type for over 15 years, so it will take some effort :). It's interesting why no one seems to have thought of this before. In general, the way to resolve ambiguities in Ada is to use more of the full name. Somehow that never occured to me in this context. -- -- Stephe
From: Hibou57 (Yannick Duchêne) on 6 Nov 2009 06:34 On 6 nov, 11:26, Stephen Leake <stephen_le...(a)stephe-leake.org> wrote: > "Vincent Marciante" <vmarcia...(a)decilog.com> writes: > > "Stephen Leake" <stephen_le...(a)stephe-leake.org> wrote in message > >news:u1vkdrert.fsf(a)stephe-leake.org... > >> 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. > > > That is not necessary: > > > package sdgfkjasf is -- or whayever > > > type List is ... > > > procedure jsdfks (List : sdgfkjasf.List); > > > ... > > That's the first time I've seen that suggestion. It's very > interesting. The package name has to show up every time the type is > paired with an object of the same name. But in other situations, the > package name can be left off. > > So this ends up being less noise than appending _Type everywhere. > > Just to be pedantic, it _is_ adding noise. It's just a different form > of noise than _Type. > > I'll have to try it in a semi-real project. I've been using _Type for > over 15 years, so it will take some effort :). > > It's interesting why no one seems to have thought of this before. Perhaps because this is not to be applied in a constant manner
From: Vincent Marciante on 6 Nov 2009 13:58 "Stephen Leake" <stephen_leake(a)stephe-leake.org> wrote in message news:uskcsne3h.fsf(a)stephe-leake.org... > "Vincent Marciante" <vmarciante(a)decilog.com> writes: > >> "Stephen Leake" <stephen_leake(a)stephe-leake.org> wrote in message >> news:u1vkdrert.fsf(a)stephe-leake.org... >>> 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. >> >> That is not necessary: >> >> package sdgfkjasf is -- or whayever >> >> type List is ... >> >> procedure jsdfks (List : sdgfkjasf.List); >> >> ... > > That's the first time I've seen that suggestion. Or maybe you forgot! The following is part of a old discusion to which you contributed: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Newsgroups: comp.lang.ada From: "Vincent Marciante" <marciant_rem...(a)li.net> Date: Fri, 5 Oct 2001 15:17:35 -0400 Local: Fri, Oct 5 2001 2:17 pm Subject: Re: on package naming, should the word "_pkg" be part of it? "Jeffrey Carter" <jeffrey.car...(a)boeing.com> wrote in message <snip> > John McCabe wrote: > > type Car_Type is > > record > > .... > > end record; > > procedure DoSomething (Car : in out Car_Type); > > could be replaced by: > > type Car is > > record > > .... > > end record; > > procedure DoSomething (The_Car : in out Car); > I recall reading articles about the psychology of understanding programs > (sorry, Robert Dewar, I don't have references for this, either. > Hopefully it's not just random neurons firing in my brain) that stated > that the first few characters of an identifier are the most important in > determining what you're reading. Having identifiers that are identical > for the first few characters requires more time and effort to > understand, and results in more errors in understanding. > Although both _Type and The_ are ways to resolve the type/parameter name > conflict, The_ is worse because it makes the first four characters of > every parameter name the same. > I make the type name reflect what the type contains. For example > type Car_Info ... > procedure P (Car : in Car_Info ... > This is not a popular approach, though, because it requires thought > about every type name. > -- > Jeffrey Carter What about the following: package XYZ is type Car ... procedure P (Car : in XYZ.Car ... -- Vinny <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > It's very interesting. The package name has to show up every time the type > is > paired with an object of the same name. But in other situations, the > package name can be left off. > > So this ends up being less noise than appending _Type everywhere. > > Just to be pedantic, it _is_ adding noise. It's just a different form > of noise than _Type. > > I'll have to try it in a semi-real project. I've been using _Type for > over 15 years, so it will take some effort :). > > It's interesting why no one seems to have thought of this before. In > general, the way to resolve ambiguities in Ada is to use more of the > full name. Somehow that never occured to me in this context. > > -- > -- Stephe
From: Stephen Leake on 7 Nov 2009 00:49 Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de> writes: > On 11/6/09 11:14 AM, Stephen Leake wrote: > >>> second, a rule that forces programmers to use a prefix in clients, >>> to make sure the type of "Container" can be seen immediately: >>> >>> procedure Some_Client >>> (<problem-domain-name> : List.Container; ...); >>> >>> Left_Queue, Right_Queue : List.Container; >> >> What if the problem domain is "any list"? We keep pointing this out, >> people keep ignoring it. > > > procedure Some_Client (Any_List : List.Container; ...); > procedure Some_Client (Any_List : List; ...); > procedure Some_Client (Any_List : Sequence; ...); > > > This is what I meant by hinting to the domain. Surely these are in different packages? Packages Containers, Lists, and Sequences? Then it is the package name that gives the domain; that works for me. > At least, "Any", unlike "_Type" is not from the Ada language > vocabulary. One reason to use "_Type" is precisely _because_ it means "Ada type"; there's no need to wonder about what it means. >>>>> Cf. valid Eiffel: >>>>> >>>>> local >>>>> string: STRING >>>>> do >>>>> ... -- more uses of string and STRING. Or StrINg. >> Ah; Eiffel has separate type and object name >> spaces. So I don't understand the original example; what was the >> point? > > In a dozen or so lines of subprogram text, the sequence of > characters "String" can refer to two different concepts, in Eiffel, > when you have declared string : STRING, an object and a type. So the case is not important; why did you introduce it? In another post, someone said Eiffel required <> around types; is that not true? > The reader, on seeing "String" in the lines following the > declaration, is forced to infer from context which concept was > meant. Sure, this is possible, not even difficult if you know the > language, as every Eiffel compiler demonstrates. When designing naming conventions, I always assume you know the language. In a language like C, sometimes we use conventions that are not strictly necessary, because the syntax is so bad. I have not used Eiffel, but if I assume the syntax distinguishing type from object is as good as in Ada, then I don't see a problem here. > But I don't want to assume the role of the compiler just to see what > "String" stands for. This is name overloading of two language > concepts in the very same inner scope. Even when this if formally > just fine, what's the point? The point, as always in this discussion, is to save time making up separate names for types and objects. >> Yes, this is an example of name overloading. Overloading, like any >> good thing, can be abused. > > Assuming separate namespaces for objects and types, > I can imagine programmers who find "string : STRING" > very clever. Or just a good match for some twisted programming > trick. Why make cleverness, or the appearance thereof, > easy to achieve? Good programmers will just find it natural; why introduce twisted programmers into this? -- -- Stephe
From: Stephen Leake on 7 Nov 2009 00:54
Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de> writes: > On 11/6/09 11:26 AM, Stephen Leake wrote: >> "Vincent Marciante"<vmarciante(a)decilog.com> writes: >> > >>> package sdgfkjasf is -- or whayever >>> >>> type List is ... >>> >>> procedure jsdfks (List : sdgfkjasf.List); >>> >>> ... >> >> It's interesting why no one seems to have thought of this before. > > My guess is that it has to do with expectations: > Many readers will have seen both X and X_Type as type names. > Consequently, both forms can denote a type in their expectation. > This expectation would have to be unlearned and replaced > with yet another expectation, a somewhat idiosyncratic one: > that X denotes an object and P.X denotes a type, as you > have outlined. It's only "idiosyncratic" because it's new. X is still a type name; this is actually a more "normal Ada way" of resolving a name ambiguity. > At first sight this seems better than _Type, since P.X does not > force the mixture of solution words like "X" and "meta names" from > the Ada language description like "_Type". > > But starting from the first expectation, what really matters > is X. How can we map exactly one meaning to exactly one > kind of entity presuming it is the direct name that matters? In general, Ada does _not_ require exactly one meaning for one identifier; that's what this discussion is all about. -- -- Stephe |