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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: gettext for Ada Date: Mon, 27 Nov 2017 18:48:27 -0600 Organization: JSA Research & Innovation Message-ID: References: <2c5d0dff-bc12-4b37-b8e1-ac176c3e675f@googlegroups.com> <40dc6a79-9434-4b5a-bed0-50ee1dfb74c5@googlegroups.com> Injection-Date: Tue, 28 Nov 2017 00:48:27 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="14070"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:49202 Date: 2017-11-27T18:48:27-06:00 List-Id: "Shark8" 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.