Re: gettext for Ada

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:d44669cc-9746-4c03-a0da-548cb945f4d5@googlegroups.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...
...
>> >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.

...
>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.)

The proposed feature is "case-on-(simple)-composite-types". I was just using 
it specifically as "case-on-fixed-strings".

As far as case sensitivity goes, that's easy to write by hand if the string 
is short enough. I never use a case insensitivity routine for short strings 
like options or language names, even now in Ada 95:

    if Option_Slice = "Op" or Option_Slice = "oP" or Option_Slice = "OP" or 
Option_Slice = "op" then
         Do_Operation_Option;
    elsif Option_Slice = "Oz" or Option_Slice = "oZ" or Option_Slice = "OZ" 
or Option_Slice = "oz" then
         Do_Optimization_Option;
    else
         Option_Error (10);
    end if;

The above is quite common in my code (perhap premature optimation on my 
part, knowing that a function like To_Upper is many times more expensive 
than a string compare).

...
>> >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.

Every time the underlying standard changes, the enumeration would have to be 
changed. That would make existing code incompatible (cases without others 
would no longer compile, some of the names could cause use clause conflicts, 
making existing code not compile, etc.) And the Ada Standard would have to 
be changed each such time. Doesn't make much sense.


...
>> 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)

That would require mapping every one of the thousand plus strings to an 
enumeration literal. Do you realize how much code that would take? (Each one 
would require the equivalent of the if I gave above.) It would add a huge 
bulk to any program that used the Locale package (as would the necessary 
'Image table). Yuck.

                                            Randy.