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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5bcc293dc5642650 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.204.140.67 with SMTP id h3mr1512208bku.3.1319136184172; Thu, 20 Oct 2011 11:43:04 -0700 (PDT) Path: l23ni22071bkv.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Why no Ada.Wide_Directories? Date: Thu, 20 Oct 2011 20:43:07 +0200 Organization: cbb software GmbH Message-ID: <127hfy3unefpt.src7zvlz5ce7.dlg@40tude.net> References: <9937871.172.1318575525468.JavaMail.geo-discussion-forums@prib32> <418b8140-fafb-442f-b91c-e22cc47f8adb@y22g2000pri.googlegroups.com> <7156122c-b63f-487e-ad1b-0edcc6694a7a@u10g2000prl.googlegroups.com> <409c81ab-bd54-493b-beb4-a0cca99ec306@p27g2000prp.googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: NkTZyZQzt+uRNthfI6+Hjg.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news2.google.com comp.lang.ada:14118 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2011-10-20T20:43:07+02:00 List-Id: On Thu, 20 Oct 2011 19:40:40 +0200, J-P. Rosen wrote: > Le 20/10/2011 09:37, Dmitry A. Kazakov a �crit : >> On Wed, 19 Oct 2011 16:43:08 -0500, Randy Brukardt wrote: >> >>> > The only way to safely use a UTF-8 string is opaquely, which means you can >>> > store it whole, but any operation on it is performed after decoding it. >>> > That's of course the best argument for having it be a separate type. >> Yes. It is worth to remember that Ada once was considered a strongly typed >> language... >> > Different types represent things that are of different nature. Depends on the meaning "different": 1. Differently implemented types representing same entities from the problem domain; 2. Incompatible types representing semantically different entities. > It is not > obvious that a difference in /encoding/ is sufficient to say that two > things are of different nature. #1 if encoding is not the problem domain, but an implementation detail, which should be the case for most application programming; #2 otherwise, e.g. in systems programming. > Consider also the problem with files. Is a UTF-8 file a text file? Do > you want a UTF8_IO package? Not likely. For text files I would prefer single Text_IO package consistently applying an appropriate recoding from the file encoding to the representation of the string type used in the operation. Of course, the targets, which do not support identification of the file encoding, will use the Form parameter to specify it explicitly. > A possible alternative solution could be to make UTF_8_String a type > derived from String (rather than a subtype). With conversions allowed, > you would not lose Text_IO. I don't know if we'll have time to discuss > this in Denver, but if you are serious about it, by all means get in > touch with your standardization body and let them make a comment. There > is no point in saying "that's how it should have been", and taking no > action to that effect. Yes, String types must be kept different in the sense #1 and same in the sense #2. That means that the type system should support classes (e.g. Wide_Wide_String'Class) comprising types of *different* implementation, which don't inherit representations from each other. This is not an issue of strings. It is a general problem, which must be approached generally. So far Ada has classes of shared representations for which upcasting and downcasting are view conversions. Classes of different representation should have physical conversions for T<->T'Class, T->S etc, creating new objects. Yes, it is inefficient, but when efficiency is an issue the type specific operations could always be overridden rather that inherited through conversion. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de