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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,83568e4f0ce7998e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.180.84.234 with SMTP id c10mr1322499wiz.4.1351381575125; Sat, 27 Oct 2012 16:46:15 -0700 (PDT) Path: q13ni63558wii.0!nntp.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bill Findlay Newsgroups: comp.lang.ada Subject: Re: Alternative syntax for function definitions? Date: Sun, 28 Oct 2012 00:46:14 +0100 Message-ID: References: Mime-Version: 1.0 X-Trace: individual.net KhI2dbMoeKY7aLjPGqBe+A6tVEtsninq7YFOdHSPDH67Y8gBq/q4kGqGz7TjWrZjlI Cancel-Lock: sha1:aGRUcUlCCu2ynteQhaj91rvj2PU= User-Agent: Microsoft-Entourage/12.33.0.120411 Thread-Topic: Alternative syntax for function definitions? Thread-Index: Ac20nT/8h26m1QzxbkS9c2WXzBLFwA== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: 2012-10-28T00:46:14+01:00 List-Id: On 27/10/2012 12:13, in article op.wmt35luxule2fv@cardamome, "Yannick Duch�ne (Hibou57)" wrote: > A dirty practical case will tell the story better. > > > type T is ...; > > type R > is record > A : T; > B : T; > C : T; > end record; > > Say the above is OK. > > Later ... > > > type T is ...; > > type R > is record > A : T; > B : T; > end record; > > function C (A : R) return Natural is (...); > > Looks fine, but somewhere else: > > X : R; > Y : Natural := X.C; > > Ouch, does not compile any more, while the program logic is still the > same, and no name has changed. ... > Some one say: hey, you are using an old legacy record, use a tagged record > instead! > > type T is new Natural; > > type R > is tagged record > A : Natural; > B : Natural; > end record; > > function C (A : R'Class) return Natural is (0); > > Looks as much fine, but somewhere else, it's fine too (better): > > X : R; > Y : Natural := X.C; > > > Just does not work with procedure, though. Thus > > X.C := Y > > Will still be broken, even with a tagged record, which does not solve that > case. OK. > Honestly, there is another way, which is to never expose record fields in > public part, and always use function/procedure. But that tends to produce > the same issue has the one which was solved with the introduction of the > �use type� clause. When I do �X.C�, I see it as the same as what �use > type� do. You lose me there. > I can't make my mind between these two strategy. Using records to expose > interface works fine only with tagged records (and only for functions to > read, not procedures to write); using function/procedure to expose > interfaces is often noisy (that's why I was thinking about this syntax > variation, in the initial post, among other things, I did not tell). I think we are groping back to the 'uniform referent' idea: that the syntax of an access should not vary according to its implementation. Ada has always made nods in that direction, and makes more with Ada 2102; but I dare say yet further improvements could be made. In the absence of these ameliorations, I use all three techniques: public record types, private record types, and tagged types; chosen according to the semantic circumstances, likely future needs, and anticipated performance issues. Getting that right(ish) is not a matter of following rules or adhering to a dogma. It is a matter of experience and good judgement. No linguistic technology can substitute for these qualities, although it can certainly help. And if the record really is 'legacy', foisted on you be a predecessor, your own better judgement is not much help. I symapathize. 8-) -- Bill Findlay with blueyonder.co.uk; use surname & forename;