From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-65-14.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-3.2 required=3.0 tests=BAYES_00,NICE_REPLY_A,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Jeffrey R.Carter" <spam.jrcarter.not@spam.acm.org.not>
Newsgroups: comp.lang.ada
Subject: Re: Looking for feedback: ISO 3166-1 country Country Code Reference
 in Ada
Date: Mon, 17 Apr 2023 11:36:53 +0200
Organization: A noiseless patient Spider
Message-ID: <u1j3vm$2va2c$1@dont-email.me>
References: <1fdb945b-fc6d-41dd-9c27-41a7fe9019fdn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Apr 2023 09:36:54 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="27767de2b3a2081c8e0f533e25867ae7";
	logging-data="3123276"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+hwa86x8IaWiHDBzVPXCsNdDmd211fUTg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Cancel-Lock: sha1:ZkVJy9VqG0VoUyKCIHnKMY3OBdA=
In-Reply-To: <1fdb945b-fc6d-41dd-9c27-41a7fe9019fdn@googlegroups.com>
Content-Language: en-US
Xref: news.eternal-september.org comp.lang.ada:65102
List-Id: <comp.lang.ada>

On 2023-04-15 20:52, A.J. wrote:
> I just created a library for accessing ISO 3166-1 records in Ada compatible with Ada.Locales. Before I try to publish it to Alire, I'm hoping to get some feedback if anyone has some. It's possible that feedback will result in the function calls, naming convention, or structure being set up differently, so please let me know what you think.
> 
> https://github.com/AJ-Ianozi/iso_3166

Some initial thoughts on what you have:

It seems likely that your clients will use the alpha codes for input and 
display. It will be more convenient for that if the alpha codes are subtypes of 
String rather than distinct types.

Since you have already enumerated all 250 possible alpha codes, your predicates 
could look like

subtype Alpha_Code_2 is String (1 .. 2) with
    Dynamic_Predicate => Alpha_Code_2 in "AF" | "AL" | ...;

and similar for the 3-letter codes.

Since you have already enumerated all 250 possible numeric codes, you could use 
a restricted range for your numeric (sub)type, with a predicate restricting it 
to valid values.

These use the language to do validity checking for you.

Regarding the design of such a pkg, my initial instinct was to use enumeration 
types for the alpha codes, but a little investigation shows that some of the 
codes are Ada reserved words, so that doesn't work. So I would stick with the 
String subtypes and provide functions such that, given one of the values, the 
client can obtain the others, as well as the name. Alternatively, one could have 
functions to return a record such as you provide. Which is preferable depends on 
how such a pkg is typically used.

There are various possible implementations, with different tradeoffs.

-- 
Jeff Carter
"He nevere yet no vileynye ne sayde
In al his lyf unto no maner wight."
Canterbury Tales
156