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.3 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,228dbf2f126edf08 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-21 12:54:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!ra.nrl.navy.mil!dca6-feed2.news.algx.net!allegiance!newsfeed1.cidera.com!Cidera!netnews.com!fr.clara.net!heighliner.fr.clara.net!freenix!enst!enst.fr!not-for-mail From: sk Newsgroups: comp.lang.ada Subject: Re: ADA and return functions (Strings) Date: Tue, 21 May 2002 14:52:26 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: References: <3ce75220@news.comindico.com.au> <5ee5b646.0205190630.237196b3@posting.google.com> Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 1022010842 34222 137.194.161.2 (21 May 2002 19:54:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Tue, 21 May 2002 19:54:02 +0000 (UTC) Return-Path: X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-4.3mdk i686) X-Accept-Language: en Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:24478 Date: 2002-05-21T14:52:26-05:00 Hi, dennison@telepath.com (Ted Dennison) : > If one were to use the same mechanisim that those ... I had of course forgotten the "local" nature of the tick-io substitution. With respect to > type DD_MM_YY_HHMMSS is new Ada.Calendar.Time; ... I tend to keep a package of Images lying around for these kinds of situations. "Jean-Pierre Rosen" : > ... OTOH, redefining 'image brings you nothing ... I agree that nothing is gained ... ... but it would be interesting to see how many people almost automatically build their own image functions rather than use the predefined ones ... ... and also, how many people tend to avoid at all costs using instantiations of Ada.Integer_Io and kin along with Ada.Strings to build these Image functions ? Anyway, I have no concern other than curiosity over the issue. It would seem however, that putting the definition of 'Image formats in the user domain rather than the language standard would allow for the standard to focus on core features rather than periphery issues. -- ------------------------------------- -- Merge vertically for real address ------------------------------------- s n p @ t . o k i e k c c m -------------------------------------