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 7 Nov 2009 00:57 "Vincent Marciante" <vmarciante(a)decilog.com> writes: > "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! Always possible. > The following is part of a old discusion to which you contributed: <snip> I don't see your point; that old discussion does _not_ propose using <package>.<type> to resolve the ambiguity. -- -- Stephe
From: Stephen Leake on 8 Nov 2009 04:48 Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de> writes: > On 11/7/09 6:49 AM, Stephen Leake wrote: > >> One reason to use "_Type" is precisely _because_ it means "Ada type"; >> there's no need to wonder about what it means. > > But the language meaning of "type" does not help with > the mentioned Message_Type_Type? > If I stubbornly follow your conventions as I understand them, > I'd have to write > > procedure Something (Message_Type : in Message_Type_Type); > or > procedure Something (Message_Type : in Message_Types.Message_Type); > > wouldn't I? Yes. This is the only special case, and usually I just stubbornly follow the convention. You get used to it. Another choice is to use Message_Label instead; procedure Something (Message_Label : in Message_Label_Type); >> In another post, someone said Eiffel required<> around types; is that >> not true? > > I mentioned Dylan where you would write string : <string>; Ah, sorry for the confusion. > > In Eiffel, and in hypothetical 2-namespace-Ada you write STring: > STring, if you want to. The visual difference is none. Is the > difference in meaning perfectly clear in the body lines following > the declaration? No, there are times when either an object or a type could be used, in attributes. Which is probably why Ada has a single namespace. >>>> 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? > > OK, I thought that the design of a general purpose programming > language, together with the naming conventions surrounding it, > should be manageable by a general public of programmers, not just > "programmers who find this natural" =:def "good programmers". > Some good programmers, in fact language makers, > have made String : String impossible. Yes, for good reasons. > Supposedly, then, they did not deem String : String a natural thing, > even though they were good programmers. That's a stretch! Avoiding actual ambiguities is a better reason. But I don't presume to read their minds. It would be interesting to read some rationale on this; I don't think there is any in the Ada Language Manual. > Before turning back to Ada and naming conventions, let me > stress the analogy, regarding Ada programmer skills. > What about C programmers who are writing programs even > though they don't know every detail about C's "int"? They are undereducated programmers, by definition. > They are writing programs controlling machines that affect our daily > lives. Should they not? They should not. > Should we shape a language and conventions around the idea that > "int" is fine in the hands of brilliant programmers and that other > programmers should seek different occupations? No, we should shape languages that are easy to learn. > In any case, the above speakers will not accept the group of normal > programmers as a premise; mostly because doing so will show C's > imperfections when in the hands of imperfect programmers, *to* *a* > *degree* that is largely caused by C---it could be less (which is > why Cyclone is different, I should think). And why Ada is different. > Those speaking in favor of C's "idiosyncrasies" like "int" deny the > normal situation of imperfect programming... I don't know how "normal" it is to be programming in C and not understand "int". I would hope it is not common at all! > This is why I am skeptical of naming conventions that need twisted > knowledge, like List : in out List. I deny that this is "twisted"; that was the point of my response. It makes perfect sense in English; we often use the same word to refer to an item or a group. More commonly we use a plural form, but often the plural form is the same as the singular. "List : Container" is no better and no worse in English. > My claim is that if Ada allows List : in out List, then there > will be a growing number of programmers who "save time making > up separate names" and routinely use T : T. Yes! Then we will have more time for other things, like coming up with good names for the other parameters. You seem to be implying that this is a bad thing; what, exactly, is the downside? > To support this claim, I think I can point at another time saver: > Anonymous "access" was introduced with Ada 2005. People like it. One > reason is that it saves time making up pointer type names. (Viz. > why, instead of declaring pointer types, not just add Foo* and &Bar > like we are used to? Of course, I meant "X : access Foo;" and > "Bar'Unchecked_Access"? Easy. Saves time.) 'Unchecked_Access is _not_ the same as as 'Access. Introducing bogus arguments is not a good arguing tactic. What is your point here? You seem to be implying that anonymous access types are bad, but you don't say so. I disagree that they are bad. > IMO, the effect of naming conventions is first and foremost an > effect on human Ada programmers, caused by human programmers. > The language definition will influence naming conventions, > but this is accidental. Yes, no one has said otherwise. In this case, the fact that the language design has a single namespace for objects and types leads to the need for a convention to distinguish the two. I argue for a simple mechanical convention; append _type to type names. Others argue for a complex time-consuming convention; come up with different names. Others also argue that types and objects should have names that differ by more than a suffix for other reasons. Several attempts have been made to explain those other reasons; as I understand it, they all come down to this: Names should convey as much information as possible, thus they should be domain-specific whenever possible. Thus the natural names for objects and types are different in many situations. To which the reply is: When the domain is very general, very general names are appropriate, and the natural object and type names are the same. Then _Type (or some similar noise) is necessary. One could then suggest a relaxed convention: Append _Type if the type name is very general, use a domain-specific name otherwise. I never seriously considered the latter; it involves deciding whether a name is "very general", which is even harder than coming up with different names. It's far easier to just use _Type. Also, I prefer writing reusable code, which tends to be domain-independent. If I'm working on robots, and I need a vector math package to compute the robot positions, I don't call it robot_position_vectors, I call it vectors. And it's generic in the floating point type, which is just named Real_Type, not Meters, or Radians, or Positions. Concrete objects in the robot code are call Pos_Joint_n, Pos_Tool, etc. Parameters to subprograms tend to have more generic names. -- -- Stephe
From: Vincent Marciante on 9 Nov 2009 13:25 "Stephen Leake" <stephen_leake(a)stephe-leake.org> wrote in message news:u639mop0u.fsf(a)stephe-leake.org... > "Vincent Marciante" <vmarciante(a)decilog.com> writes: > >> "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! > > Always possible. > >> The following is part of a old discusion to which you contributed: > > <snip> > > I don't see your point; that old discussion does _not_ propose using > <package>.<type> to resolve the ambiguity. My point was to show that my mentioning using <package>.<type> to resolve ambiguity nicely in my first message was actually not the first time that it was mentioned (ever if not explicitely) in c.l.a. I probably expected that seeing that simple example would be enough to cause a mental "click" regarding some benifits of that construction. No big deal, as long as there may now be at least one less "_Type" writer. ;) (Note that I wrote alittle more in one of your other messages in the thread regarding original Ada rationale.) Vinny > > -- > -- Stephe
From: Vincent Marciante on 9 Nov 2009 14:09 "Stephen Leake" <stephen_leake(a)stephe-leake.org> wrote in message news:u3a4pqrcz.fsf(a)stephe-leake.org... > Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de> writes: > >> On 11/7/09 6:49 AM, Stephen Leake wrote: >> >>> One reason to use "_Type" is precisely _because_ it means "Ada type"; >>> there's no need to wonder about what it means. >> >> But the language meaning of "type" does not help with >> the mentioned Message_Type_Type? >> If I stubbornly follow your conventions as I understand them, >> I'd have to write >> >> procedure Something (Message_Type : in Message_Type_Type); >> or >> procedure Something (Message_Type : in Message_Types.Message_Type); >> >> wouldn't I? > > Yes. This is the only special case, and usually I just stubbornly > follow the convention. You get used to it. > > Another choice is to use Message_Label instead; > > procedure Something (Message_Label : in Message_Label_Type); > >>> In another post, someone said Eiffel required<> around types; is that >>> not true? >> >> I mentioned Dylan where you would write string : <string>; > > Ah, sorry for the confusion. > >> >> In Eiffel, and in hypothetical 2-namespace-Ada you write STring: >> STring, if you want to. The visual difference is none. Is the >> difference in meaning perfectly clear in the body lines following >> the declaration? > > No, there are times when either an object or a type could be used, in > attributes. Which is probably why Ada has a single namespace. > >>>>> 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? >> >> OK, I thought that the design of a general purpose programming >> language, together with the naming conventions surrounding it, >> should be manageable by a general public of programmers, not just >> "programmers who find this natural" =:def "good programmers". >> Some good programmers, in fact language makers, >> have made String : String impossible. > > Yes, for good reasons. > >> Supposedly, then, they did not deem String : String a natural thing, >> even though they were good programmers. > > That's a stretch! Avoiding actual ambiguities is a better reason. But > I don't presume to read their minds. It would be interesting to read > some rationale on this; I don't think there is any in the Ada Language > Manual. What I gathered was that the original chief language designer constructed the language rules with a goal of trying to drive/impose the necessity of "good" program architecture and trying to prevent/discourage "bad" program architecture and I think that the following was one of the things that was to be promoted: - separating (having in different packages) the declaration of types (abstract data types) and object of the type. I think that having two namespaces would have made having both in the same declarative region easier but that would only really come up for the type and only one object (or as a yucky "workaround") an array of them) declared together. Clearly, whenever there are two objects of the type, the simple name of one of them _must_ be different than the name of the type unless they are in different declarative regions. I think that separate object and type namespaces would simply have been redundant. Also, I showed that the "parameter of subprogram declaration" case (which was the old example that I brought up in an earlier message) is easily and elegantly dealt with by the sjkdf.type_name construct So, that there is really no need for two namespaces but there also is really is no need for any overall naming convention either! As to why there is "File_Type" in Text_IO instead of various Sub(File:Text_IO.File) declarations, I'd for a couple of reasons) say it was just a "mistake" due to expediency. My reasons are: (1) The big text_IO package was not part of the original language, it was added (relatively quickly?) in order to reduce the amount of generic instantiations that would be required to do simple io. (2) The original chief designer afterward acknowlegded/commented that he thought that even having text_io depend on the predefined "integer" was a mistake. With all of that I am not trying to be be "diffinative" in any way, I'm just putting out what I remember and (though about) from earily on at the start of my use of Ada. I hope that at least some of what I wrote is at all useful (and that none of it is inacurate!) Vinny
From: Stephen Leake on 10 Nov 2009 02:51
"Vincent Marciante" <vmarciante(a)decilog.com> writes: >>>> That's the first time I've seen that suggestion. >>> >>> Or maybe you forgot! >> >> Always possible. >> >>> The following is part of a old discusion to which you contributed: >> >> <snip> >> >> I don't see your point; that old discussion does _not_ propose using >> <package>.<type> to resolve the ambiguity. > > My point was to show that my mentioning using > <package>.<type> to resolve ambiguity nicely > in my first message was actually not the first > time that it was mentioned (ever if not explicitely) > in c.l.a. I still don't get it. If it was not mentioned explicitly, how was it mentioned? If I had seen that suggestion before, I might be using it now. > No big deal, as long as there may now be at least > one less "_Type" writer. ;) Not likely, after 15 years of habit forming. -- -- Stephe |