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-Thread: a07f3367d7,25d835bb9a4a003f X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!news2.euro.net!newsfeed.freenet.de!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sat, 07 Nov 2009 15:28:43 +0100 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Types, packages & objects : the good old naming conventions question (without religious ware) References: <4ae9dade$0$6551$9b4e6d93@newsspool4.arcor-online.net> <4aef3911$0$7617$9b4e6d93@newsspool1.arcor-online.net> <4af2ba89$0$6566$9b4e6d93@newsspool4.arcor-online.net> <4af42f5b$0$7624$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4af5841f$0$6583$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 07 Nov 2009 15:28:47 CET NNTP-Posting-Host: 053d3103.newsspool3.arcor-online.net X-Trace: DXC=b280R[<=Caig`45cDR8l?oMcF=Q^Z^V3h4Fo<]lROoRa8kFfNfPCY\c7>ejVhMSR?EIIlWj`ZK_]QgXLeob X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:9026 Date: 2009-11-07T15:28:47+01:00 List-Id: 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? (I speculate that one could add a remark about first class type objects here, as per Dmitry's suggestion. More confusion.) >>>>>> 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? The "String : String" part of the declaration means -object-named-String- : -type-named-String- in Eiffel. The very same word names both the object and the type. Characters case is important to the reader, however (you have mentioned GNAT's warnings). The writer may like to use case distinction to "disambiguate" the same sequence of letters. That's fine as long as you live in a single universe of formal names, like when you are working on the same set of Ada programs for months, and never need to look elsewhere. > In another post, someone said Eiffel required<> around types; is that > not true? I mentioned Dylan where you would write string : ; 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? > 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? 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. Supposedly, then, they did not deem String : String a natural thing, even though they were good programmers. Here is an analogous example. The argument (be a better programmer if you want to use our language properly) is popular. Whenever I had the courage to mention that there are sharp corners in C and that, therefore, we should be expecting these corners to cause trouble, I heard it: programmers causing trouble in C programs lack education! Well... Proof of trouble is the weekly CVE report about C programs and the type "int". That's am empirical fact. QED. Is it an empirical fact that most programmers lack education? Or does C have some dangerous imperfections? The typical response is a exaggeration of your question: Why count stupid non-C-knowing less than excellent programmers in the select set of programmers-finding-C-natural who know by heart the C standard and the compiler documentation? ("Because we live on planet earth!" is what I think, then. "A language, or a naming convention, should respect this fact.") 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 writing programs controlling machines that affect our daily lives. Should they 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? 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). Those speaking in favor of C's "idiosyncrasies" like "int" deny the normal situation of imperfect programming... This is why I am skeptical of naming conventions that need twisted knowledge, like List : in out List. 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. 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.) 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.