From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Types, packages & objects : the good old naming conventions question (without religious ware) References: From: Stephen Leake Date: Fri, 30 Oct 2009 06:48:28 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) Cancel-Lock: sha1:7VBL2k9rnn48Ze0bf5A4tAUOQj0= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 04b4f4aeac47ae197caa718538 Xref: g2news2.google.com comp.lang.ada:8889 Date: 2009-10-30T06:48:28-04:00 List-Id: "Hibou57 (Yannick Duchêne)" writes: > Hi, > > Still reading a new chapter of the Ada 95 Quality and Style Guide, the > “ CHAPTER 3: Readability ” ( http://www.iste.uni-stuttgart.de/ps/ada-doc/style_guide/sec_3a.html#3.2.1 > ) has inspired me to ask for more about the subject. > > The one which troubles me the most, is the most common convention > about type names, without a suffix. This one is very common, and so > much common that even the Ada standard packages set relies on it. Not entirely; Ada.Text_IO.File_Type, and others, follow the _Type convention (which is the better convention :). > A long time ago, a time when I was using Pascal, I wondered about this > topic (without any guide at the time), and tried something which was > the same as this seemingly most commonly used Ada convention, but I > ended into troubles with most of type names, which were conflicting > with the most obvious name of objects. Not all the time, but oftenly. Right, this is the reason for using _Type on type names. > I do not mean I'm surprised this convention is working fine with the > Ada standard packages set, I know there is probably a reason which > explains why it works in this one case : It works for the standard because people are very flexible, and can work around quirks like this while convincing themselves it's better. It would take less effort to use a package if all types followed the _Type convention. Then more people would have more time to write more Ada code, and we'd take over the world. > A basic type may be Integer, as a basic type Integer is a very > abstract thing, and as a very abstract thing, this will not conflict > with the name of a very concrete thing. Parameters are very abstract things as well; that's where most object/type name conflicts occur: procedure Sort (List : in out List) which occurance of "List" is less abstract? Better to not have to think about it. > That's why I'm wondering if in the Ada area, people really use or not, > the convention without a suffix. I can guess it works find with Ada > standard stuff, for the reasons introduced just before, but it is more > difficult to me to imagine how this same convention can practicably > works as much fine with larger projects dealing with much more > concrete types. Right. Just use _Type; life will be better. And the more code people write with _Type, the sooner everyone will be converted to the One True Way. > This convention which consist of the use of the suffix _Type, is > referred to in this chapter, so it means it is a well known > convention, while in the mean time, I had never see it recommended in > any Ada style guide. To be short : seems to be known, but seems to be > fully unused in real projects (except perhaps in students works). I use it in my projects: http://www.stephe-leake.org/ http://gds.gsfc.nasa.gov/ > It's easy to accept large scale projects as being a proof of the > relevance of a naming convention. No, just proof of the flexibility, stubborness, and differences in opinion among people. > 1) how the name collision troubles between highly specialized type > names and instance names can be resolved with a convention which > does not rely on a dedicated suffix or prefix for type names ? It can't. Objects and types share the same name space. There are only two choices: a) use a convention to split this into two name spaces (trailing _Type is the most common convention; others are possible). b) spend extra effort on each object coming up with a name that is different than the type. > 2) Is the convention with a suffix really not used (as it appears to > not be) ? No. > Now another stuff, still about naming convention : Better to start another thread for a different topic. > This Chapter 3 also introduced two main naming convention schemes, one > which seems to comes from who-know-who, and one which comes from JP > Rosen. > > At first sight, I was a bit surprised by the one suggested by JP > Rosen. In short, I silently though “ all main type defined in a > package has the name Instance, and its class wide view has the name > Class... this is the least expressive things one may imagine, I don't > want this ”. But later, I figured out that in practice, this may be > indeed relevant because this is not the name of the type which > identify what it is, but rather its package name. That depends on whether you use "use" clauses: with Bar; with Baz; procecure Foo is A : Bar.Instance; B : Baz.Instance; ... end Foo; or: with Bar; use Bar; with Baz; use Baz; procedure Foo is A : Some_Bar_Type; B : Some_Baz_Type; ... end Foo; This is more a matter of style and personal taste than the _Type issue. Even in this case, Instance_Type would be better; then the subprograms in Bar could use Instance as a parameter name. -- -- Stephe