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,UTF8 Path: g2news2.google.com!news1.google.com!news.glorb.com!feed.xsnews.nl!border-1.ams.xsnews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer0.kpn.DE!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Factory Pattern From: Georg Bauhaus In-Reply-To: <1185695674.206091.43870@w3g2000hsg.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> <1185541668.089363.258220@q75g2000hsh.googlegroups.com> <1185695674.206091.43870@w3g2000hsg.googlegroups.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Organization: # Message-Id: <1185706427.8471.29.camel@sonnenregen> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Date: Sun, 29 Jul 2007 12:53:47 +0200 NNTP-Posting-Date: 29 Jul 2007 12:53:48 CEST NNTP-Posting-Host: b001da1e.newsspool3.arcor-online.net X-Trace: DXC=cA9_:Dc1j@5TQL:hoD@>T?McF=Q^Z^V384Fo<]lROoR1^YC2XCjHcb9NA8A]A?:CY0A:ho7QcPOV3Ga2Rf_kiQT1@ILjIGRj^:8 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:1261 Date: 2007-07-29T12:53:48+02:00 List-Id: On Sun, 2007-07-29 at 00:54 -0700, Maciej Sobczak wrote: > On 28 Lip, 00:23, "Randy Brukardt" wrote: >=20 > > (New standards for other languages also will have to add > > this sort of support, or take their chances at having their standards f= ail.) >=20 > When I think about it more, I cannot even believe it might be true. > Consider... C. It has the ISO standard and surely will be revised. >=20 > One of the things that are taken for granted in the whole industry is > the fact that C names are immediately "extern" without any further > tweaking. Thanks to this you can write >=20 > pragma Import (C, Puts, "puts"); >=20 > and gain access to the standard puts function in C. This does right now depend on the combination of tools, unfortunately. However, names across languages are being considered in new language revisions and are aware of Unicode (or ISO 10646). > Now imagine that C introduces support for Unicode in names. No need to imagine things, as Unicode inclusion has already happened. There are also C compilers and C++ compilers documenting how to use Unicode identifiers, and their users report sucess (I think a D compiler with Unicode support is available, too). "WG14/N1124 Committee Draft =E2=80=94 May 6, 2005 ISO/IEC 9899:TC2 "6.4.2 Identifiers "3 Each universal character name in an identifier shall designate a character whose encoding in ISO/IEC 10646 falls into one of the ranges specified in annex D. [60] "[60] On systems in which linkers cannot accept extended characters, an encoding of the universal character name may be used in forming valid external identifiers. For example, some otherwise unused character or sequence of characters may be used to encode the \u in a universal character name. Extended characters may produce a long external identifier. "Annex D (normative) Universal character names for identifiers 1 This clause lists the hexadecimal code values that are valid in universal character names in identifiers." Roughly the same wording is found for C++ in=20 http://www.open-std.org/jtc1/sc22/open/n2356/ Annex E > Am I missing something? I think yes. Unicode identifiers are already allowed, though not by every compiler. Linker tools are standardizing on mangling rules. The rules are more programmer friendy in that they can use names that many systems can use, for example UTF-8 names (UTF-8 has been around in final form since 1992, see the interesting remarks by Rob Pike in http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt ) Character set representations have been differing around the globe and within one country and between machines. This isn't surprising when there are competing computers, and languages that are different between nations (thinking of EBCDIC, Sun SPARC,=20 embedded and mobile computers in Japan, Korea, =E9=A6=99=E6=B8=AF (Hong Kon= g) ...).