Re: gettext for Ada

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, November 22, 2017 at 5:30:28 PM UTC-7, Randy Brukardt wrote:
> "Shark8" wrote in message 
> 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 2020
> >> extension comes to pass) to select them.
> >
> >Are you talking about a case-statement for selecting a child package, 
> >perhaps something like:
> > PACKAGE Actual_Messages RENAMES (CASE Language is
> >   WHEN English => Messages.English, WHEN German => Messages.German,
> >   WHEN French => Messages.French, WHEN OTHERS => Raise Program_Error)
> >?? -- or something like case-selection on strings? -- or something 
> >different altogether?
> 
> Case selection on fixed length strings (which these are). Would need an 
> others clause, of course.

Is it a case-insensitive string comparison? Because case-sensitive would make your cases explode exponentially if it weren't... and if they ARE case-insensitive 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 the 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 could 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 ways generics could be extended: (a) allowing non-generic packages as parameters, 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 generic subprograms in a manner like current generic packages may be parametrized; (c) easing some restrictions on incomplete formal parameters, allowing a function returning said type to be used.}

> 
> >> Or (perhaps better), use a full OOP design, with an abstract Root_Locale
> >> type (with a set of dispatching operations), a series of specific Locale
> >> types (English_Locale, French_Locale, etc.) giving implementations to 
> >> those
> >> types, and a map and factory to create objects of those types as needed.
> >> (The Claw GUI Builder has an internal design much like this, other than 
> >> 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?
> 
> Claw is still pure Ada 95 code.

Ah, I see.
I remember you mentioning that Janus/Ada had a few Ada 2005 features implemented and was wondering if perhaps something like updating Claw (or some similar SW package) was the/a motivating factor.

> 
> >> > 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 them 
> >> is
> >> next to impossible. We decided against even giving names to the most 
> >> common
> >> ones, as that would have led to endless debates about which ones are the
> >> 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 depend 
> >> on
> >> character set standards rather than rolling our own character set rules
> >> (even though the latter would be easier to maintain, we wouldn't really 
> >> know
> >> what we were doing).
> >
> >Er... "The strings come from a freely available ISO standard, so they will 
> >never change"
> >
> >So why not enumerate the strings, that way proper cases can be done on 
> >either languages and/or locales?
> 
> Because the underlying Standard changes frequently, adding new languages and 
> locales. There is no practical way to do that for Ada enumerations. (Note 
> that I said the "strings don't change", meaning that the meanings of the 
> strings don't change, not that the *list* of strings doesn't change often, 
> usually with new additions.)

And? / I fail to see a meaningful distinction here.

> 
> >
> >-- ISO 3166-1 Country & Territory Codes
> >-- See: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
> >Type Locale is (
> > AF, -- Afghanistan
> > AX, -- Åland Islands
> ...
> 
> There are many hundreds of locales, and new ones are added periodically. 
> Maintaining that in the Ada standard would be a nightmare, and what 
> precisely would be the point? The same applies (even moreso) to languages.
> 
> In addition, this scheme would fail misreably if an OS update caused some 
> unknown (to Ada) locale or language to be returned. That's not possible for 
> the string scheme (as it matches both the ISO Standard and what OSes 
> 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 something that is known.