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: 103376,174ec7dc941a1068 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!news.glorb.com!news2.arglkargh.de!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Factory Pattern Date: Fri, 27 Jul 2007 17:23:30 -0500 Organization: Jacob's private Usenet server Message-ID: 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> <1185541668.089363.258220@q75g2000hsh.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1185574871 22788 69.95.181.76 (27 Jul 2007 22:21:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 27 Jul 2007 22:21:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Xref: g2news2.google.com comp.lang.ada:1230 Date: 2007-07-27T17:23:30-05:00 List-Id: "Maciej Sobczak" wrote in message news:1185541668.089363.258220@q75g2000hsh.googlegroups.com... ... > 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... ;-) For what it's worth, I agree with you and would have preferred to leave identifiers as they were in Ada 95. However, the requirement for this support came down from above; essentially, if we wanted Ada to continue to be an ISO standard, we needed to add this sort of support. (New standards for other languages also will have to add this sort of support, or take their chances at having their standards fail.) Even so, we did consider not doing it, but there was enough interest from some countries that we felt that there was quite a bit of risk that the standard would fail if we didn't add this support. To summarize: the decision to add Unicode identifiers was political, not technical. Complaining about it on technical factors has about as much relevance as trying to decide a major national issue on merits (say health-care in the US) -- the technical factors are virtually irrelevant. Randy.