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!aioe.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: The extension of Is_Basic to unicode (about AI12-0260-1) Date: Thu, 12 Apr 2018 07:14:12 +0200 Organization: Adalog Message-ID: References: <7d5b8717-1e70-4153-af13-dfab24679ed9@googlegroups.com> <6518518c-5153-4afd-a2c5-d173ec0fe268@googlegroups.com> NNTP-Posting-Host: XdjV4tYMtFfMKGpv0MuDzQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Content-Language: fr X-Notice: Filtered by postfilter v. 0.8.3 Openpgp: preference=signencrypt Xref: reader02.eternal-september.org comp.lang.ada:51457 Date: 2018-04-12T07:14:12+02:00 List-Id: Le 12/04/2018 à 01:57, ytomino a écrit : > If Character.Handling.Is_Basic can not be changed because > compatibility, still more, this *overloading* will create new problem > for the future. > > For example, on rewriting some applications from Character to > Wide_Character, it may be imagined that two meanings of Is_Basic will > confuse. > Or, they makes hard to use "use clause", or use as a generic formal > subprogram. If you are adapting a program to use the full BMP instead of Latin1, expect many more difficult issues and/or incompatibilities than this one... > Excuse me for repeating, should new function name be used for new > definition? > > function Is_Base (Item : Wide_Character) return Boolean; -- according with Unicode > function Is_Basic (Item : Wide_Character) return Boolean is (Is_Base (Item) and Is_Letter (Item)); -- for compatibility This is technically doable, but not obviously desirable. This incompatibility seems to me to be a candidate to the following comment, already used for some other incompatibilities: "This incompatibility is likely to fix more bugs than it will create" -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr