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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,174ec7dc941a1068 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!q75g2000hsh.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Factory Pattern Date: Fri, 27 Jul 2007 06:07:48 -0700 Organization: http://groups.google.com Message-ID: <1185541668.089363.258220@q75g2000hsh.googlegroups.com> References: <1185387571.367570.163160@r34g2000hsd.googlegroups.com> <1185432247.046242.24300@o61g2000hsh.googlegroups.com> <1185439242.28126.36.camel@kartoffel> <1185447702.28126.57.camel@kartoffel> <1185454958.105983.143570@l70g2000hse.googlegroups.com> NNTP-Posting-Host: 137.138.37.241 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1185541668 20974 127.0.0.1 (27 Jul 2007 13:07:48 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 27 Jul 2007 13:07:48 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070724 Red Hat/1.5.0.12-0.3.slc3 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: q75g2000hsh.googlegroups.com; posting-host=137.138.37.241; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:1226 Date: 2007-07-27T06:07:48-07:00 List-Id: On 27 Lip, 00:31, "Randy Brukardt" wrote: > > In the case-insensitive programming language I would > > expect that changing the "case" of one character in the identifier > > will not change its semantics. How Ada guarantees this for Unicode? > > It uses the Unicode-defined case mapping tables. > If you really care how these things are defined, check out the standard > clauses 2.1 and 2.3. Thank you for pointing this. > > Sorry, I don't call it "well-designed". > > Well, that's your choice, but it would be better informed if you understood > the rules in question first. Yes, with the rules as described in ARM no such problems should arise, at least with the use of tools that are part of the langauge implementation (compiler or interpreter or whatever). Still, I don't share the motivation for introducing such support into the language. There are two reasons for this: 1. The programming language does not exist in a vacuum and the typical software development process involves many more tools than just a compiler. Text editor might be useful as well, not mentioning countless utilities for automated text processing. They are not covered by ARM and do not have to follow its rules. This makes it more difficult to work with code that liberally uses Unicode or case- agnostic naming - and can be an additional source of mistakes. This additional burden and the risk of mistakes is against the Ada spirit (as I understant it). 2. There is no way to escape English and Latin1 character set anyway. Not only Ada is very rich in reserved words, there are also tons of names in the standard library. All these are English and Latin1. In addition, there are third-party libraries, code is moved from one project to another, projects are published, companies merge, etc. This means that a programmer wanting to use her hieroglyphs in the Ada program cannot be consistent with any convention. I, for example, find it very disturbing when I see in a single line of code two names in different languages and all the companies and projects I've been involved in prohibit(ed) such mixes without exceptions - note that I'm not a native English speaker, so such rules relate to me directly. Interestingly, using localized identifier names does not increase readability of the program! Again, not Ada spirit (as I understand it). OK, let's better write some more Latin1 code with standard naming convention... ;-) -- Maciej Sobczak http://www.msobczak.com/