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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Question on bounded / unbounded strings Date: Thu, 22 Sep 2016 11:53:55 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <11ee98f5-d373-4c72-8562-c310cc76817d@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:31839 Date: 2016-09-22T11:53:55+02:00 List-Id: On 22/09/2016 11:01, J-P. Rosen wrote: > Le 22/09/2016 à 09:24, Dmitry A. Kazakov a écrit : >> Neither do I, I never ever used bounded strings. They are totally >> useless, IMO. > No, they are not. > > A bounded string is perfectly appropriate to represent abstract data > that are /implemented/ by a string. > > Typical example: > - you want to represent a first name, a family name, and an address. > - You want them to be different types (to make it impossible to mix > them), although they are all implemented as strings. type First_Name is new String; type Family_Name is new String; type Postal_Address is new String; > - You have an underlying data base that imposes a maximum length for > each of these, but the actual length can be anything up to the maximum type Fist_Name is new SQL_C_CHAR; If you do DB you use DB data types. BTW, such external constraints, if they exist, are pretty much volatile. You don't want to make them static that would make the design very fragile. > => Bounded_String is the way to go. Never. It is very difficult to find cases where 1. There is a hard upper bound, so hard that it would be feasible to mold it into the type. 2. There is no cases where the upper bound implies another type. There is nothing in the first name's length that makes first name different from the second name. These are just unrelated things. The major reason for that is that constraint whatever it be is most likely an implementation detail, which type difference is to reflect the problem space. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de