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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,2e6723b897ab47fb X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.141.225 with SMTP id rr1mr1305656pbb.2.1344847673016; Mon, 13 Aug 2012 01:47:53 -0700 (PDT) Path: g9ni51107834pbo.0!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news-in-01.newsfeed.easynews.com!easynews.com!easynews!novia!news-peer1!btnet!zen.net.uk!hamilton.zen.co.uk!xlned.com!feeder3.xlned.com!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!80.86.168.138.MISMATCH!news-feed.eu.lambdanet.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada.Locales pseudo-string types Date: Thu, 09 Aug 2012 11:31:44 +0300 Organization: Tidorum Ltd Message-ID: References: <78707b6e-88a3-453a-a37c-840f7a62e703@googlegroups.com> <7303f906-0f6a-4d97-ae15-36b4056ede6c@googlegroups.com> <257b4f44-b6c6-4c79-8c6e-dec947a3ce25@googlegroups.com> <1o3by92cb82px$.1gavjw6p23du6$.dlg@40tude.net> <8zenu4qplfb$.1uc9oi1819c3v$.dlg@40tude.net> <1oel9yro6j0vj.1a64kz67quj9u$.dlg@40tude.net> Mime-Version: 1.0 X-Trace: individual.net pCNbN27CgdPs++SoUI900wXKa9djXctjIO+3LxGpILdEqP+vedrYRR9bX3NlaW2vAK Cancel-Lock: sha1:v2vdg5NC50SCaltyWUQCLSgLH9Q= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <1oel9yro6j0vj.1a64kz67quj9u$.dlg@40tude.net> X-Received-Bytes: 5505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-08-09T11:31:44+03:00 List-Id: On 12-08-09 10:48 , Dmitry A. Kazakov wrote: > On Wed, 08 Aug 2012 17:01:23 +0300, Niklas Holsti wrote: > >> On 12-08-08 14:59 , Dmitry A. Kazakov wrote: > >>> BTW, if you go that far you should also allow conversions between any array >>> types of convertible elements. E.g. between arrays of floats and arrays of >>> integers etc. >> >> Well, for explicit value conversions, why not? But I don't think that >> there is significant need for such conversions on the array level. > > I needed to convert array of access types in some cases. But I agree that > there is no significant need in array conversion, in any array conversion, > I would add. Don't we consider conversions bad, in Ada? If so, we should > rather eliminate cases where conversions are needed, rather than inventing > more and more sophisticated ways of conversion. I think that conversions are the logically right thing in some cases, while more inheritance (which I assume is your aim) is better in other cases. I would not like to reduce the conversion abilities of Ada. >> What I have sometimes found annoying is that operations on arrays of a >> parent type cannot easily be applied to arrays of a derived type. >> For example: >> >> type Parent is (A, B, C); >> type Parent_Arr is array (Positive range <>) of Parent; >> >> procedure Print (Item : in Parent_Arr) >> ... >> end Print; >> >> type Child is new Parent; >> type Child_Arr is array (Positive range <>) of Child; > > If arrays had classes you could inherit the Parent's interface which would > bring Print with it. It is not clear to me how that would work, in detail. Either one would have to override all the operations for Child_Arr, to substitude Parent with Child, or there would have to be some implicit rules for such substitutions, which would in effect establish the same implicit relationship between Child_Arr and Parent_Arr as I feel already exists. >> The operation Print on Parent_Arr is not inherited by Child_Arr, > > Why should it? Child_Arr is unrelated to Parent. It is just a feeling, and sometimes a practical need. Surely Child_Arr is in some sense related to Parent_Arr, since Child is related to Parent, and the same type construction (array) is used in both? If a Child is-a Parent, in the sense that primitive operations for Parents are also available (inherited) for Children, why are not operations on collections of Parents available for collections of Children? A collection (array) of Children is-a collection of Parents. (This relationship could be easier to see and implement if Ada had a "sequence" type construction in addition to the "array" type construction, because then we would not have to consider the possible difference in the index types of Child_Arr and Parent_Arr. That is, if a list of elements of type T could be defined as "sequence of T" without having to choose a specific type and range to index the sequence.) > Somewhere in its > declaration Child_Arr must say "new Parent" or "and Parent." Such type > relationships must be manifested, not implied. I'm not sure that making the relation manifest in that way is important. I think that an Ada-derived language could be defined that would let Child_Arr inherit Print from Parent_Arr, without requiring this manifest relation in the syntax. Other considerations (readability, reliability) would determine the decision. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .