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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.36.54.136 with SMTP id l130mr4545401itl.22.1511406500173; Wed, 22 Nov 2017 19:08:20 -0800 (PST) X-Received: by 10.157.51.145 with SMTP id u17mr976549otc.7.1511406500067; Wed, 22 Nov 2017 19:08:20 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!d140no4106106itd.0!news-out.google.com!x87ni2554ita.0!nntp.google.com!i6no4105592itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 22 Nov 2017 19:08:19 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.113.16.86; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.113.16.86 References: <2c5d0dff-bc12-4b37-b8e1-ac176c3e675f@googlegroups.com> <40dc6a79-9434-4b5a-bed0-50ee1dfb74c5@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: gettext for Ada From: Shark8 Injection-Date: Thu, 23 Nov 2017 03:08:20 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: feeder.eternal-september.org comp.lang.ada:49089 Date: 2017-11-22T19:08:19-08:00 List-Id: On Wednesday, November 22, 2017 at 5:30:28 PM UTC-7, Randy Brukardt wrote: > "Shark8" wrote in message=20 > news:f008ea86-60a5-411d-88ab-0130bcda63a8... > On Tuesday, November 21, 2017 at 6:10:23 PM UTC-7, Randy Brukardt wrote: > ... > >> I would make a set of parallel child packages with the same operations= in > >> each. Then one could use an if (or maybe a case, if the proposed Ada 2= 020 > >> extension comes to pass) to select them. > > > >Are you talking about a case-statement for selecting a child package,=20 > >perhaps something like: > > PACKAGE Actual_Messages RENAMES (CASE Language is > > WHEN English =3D> Messages.English, WHEN German =3D> Messages.German, > > WHEN French =3D> Messages.French, WHEN OTHERS =3D> Raise Program_Erro= r) > >?? -- or something like case-selection on strings? -- or something=20 > >different altogether? >=20 > Case selection on fixed length strings (which these are). Would need an= =20 > others clause, of course. Is it a case-insensitive string comparison? Because case-sensitive would ma= ke your cases explode exponentially if it weren't... and if they ARE case-i= nsensitive I'd expect a lot of programmers (notably those of C backgrounds)= to complain. (Or is there some sort of magic/syntax to determine between t= he two?) In all, CASE-on-Strings is rather disappointing... it kinda comes off as an= "Ada also does X like Java!"-feature like INTERFACE was/is. (Interface cou= ld have, and IMO should have, been far more useful than Java's notion.) Something like extending CASE to renaming-packages or extending the GENERIC= hierarchy sounds much more useful to me. {There are several interesting wa= ys generics could be extended: (a) allowing non-generic packages as paramet= ers, which would require some ability to specify characteristics about the = publicly available properties of the specification [honestly, a LOT of work= , but could simplify the construction of standard packages]; (b) allowing g= eneric subprograms in a manner like current generic packages may be paramet= rized; (c) easing some restrictions on incomplete formal parameters, allowi= ng a function returning said type to be used.} >=20 > >> Or (perhaps better), use a full OOP design, with an abstract Root_Loca= le > >> type (with a set of dispatching operations), a series of specific Loca= le > >> types (English_Locale, French_Locale, etc.) giving implementations to= =20 > >> those > >> types, and a map and factory to create objects of those types as neede= d. > >> (The Claw GUI Builder has an internal design much like this, other tha= n=20 > >> the > >> factory, which didn't exist in Ada 95, so I had to use a massive case > >> statement instead. A factory would have been much better.) > > > >Do you still have the giant case, or did you opt to use the > > Generic_Dispatching_Constructor when Ada 2005 added it? >=20 > Claw is still pure Ada 95 code. Ah, I see. I remember you mentioning that Janus/Ada had a few Ada 2005 features implem= ented and was wondering if perhaps something like updating Claw (or some si= milar SW package) was the/a motivating factor. >=20 > >> > Also, shouldn't the stuff in Ada.Locales actually be proper > >> > enumerations rather than strings? > >> > >> There's a near infinite number of possible Locales, so enumerating the= m=20 > >> is > >> next to impossible. We decided against even giving names to the most= =20 > >> common > >> ones, as that would have led to endless debates about which ones are t= he > >> most important. The strings come from a freely available ISO standard,= so > >> they will never change and are easy to find out and are maintained by > >> someone other than us Ada people (so no need for debates on our end on > >> topics outside of our expertise). This is the same reason that we depe= nd=20 > >> on > >> character set standards rather than rolling our own character set rule= s > >> (even though the latter would be easier to maintain, we wouldn't reall= y=20 > >> know > >> what we were doing). > > > >Er... "The strings come from a freely available ISO standard, so they wi= ll=20 > >never change" > > > >So why not enumerate the strings, that way proper cases can be done on= =20 > >either languages and/or locales? >=20 > Because the underlying Standard changes frequently, adding new languages = and=20 > locales. There is no practical way to do that for Ada enumerations. (Note= =20 > that I said the "strings don't change", meaning that the meanings of the= =20 > strings don't change, not that the *list* of strings doesn't change often= ,=20 > usually with new additions.) And? / I fail to see a meaningful distinction here. >=20 > > > >-- ISO 3166-1 Country & Territory Codes > >-- See: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes > >Type Locale is ( > > AF, -- Afghanistan > > AX, -- =C3=85land Islands > ... >=20 > There are many hundreds of locales, and new ones are added periodically.= =20 > Maintaining that in the Ada standard would be a nightmare, and what=20 > precisely would be the point? The same applies (even moreso) to languages= . >=20 > In addition, this scheme would fail misreably if an OS update caused some= =20 > unknown (to Ada) locale or language to be returned. That's not possible f= or=20 > the string scheme (as it matches both the ISO Standard and what OSes=20 > actually do). No; it really wouldn't, there are enumerations that perfectly map to "I don= 't understand this"-states: >From my example: * Locale'(ZZ) * Language'(und) If you're encountering unknown-to-Ada locale/language the correct thing to = do is either FAIL (throw the appropriate exception) and/or DEFAULT to somet= hing that is known.