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,FREEMAIL_FROM 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,UTF8 Received: by 10.66.75.164 with SMTP id d4mr7333475paw.10.1351336442143; Sat, 27 Oct 2012 04:14:02 -0700 (PDT) Path: 6ni33531pbd.1!nntp.google.com!news.glorb.com!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Alternative syntax for function definitions? Date: Sat, 27 Oct 2012 13:13:59 +0200 Organization: Ada @ Home Message-ID: References: NNTP-Posting-Host: 3BwS2FG+75pYINFjPK6b7w.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.02 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-10-27T13:13:59+02:00 List-Id: Le Sat, 27 Oct 2012 11:38:06 +0200, Bill Findlay = a =C3=A9crit: > On 27/10/2012 10:02, in article op.wmtx2nxkule2fv@cardamome, "Yannick > Duch=C3=AAne (Hibou57)" wrote: > >> Le Sat, 27 Oct 2012 10:37:11 +0200, Dmitry A. Kazakov >> a =C3=A9crit: >>> That is no problem. All types should have classes anyway. The dotted= >>> notation itself is an implementation of some record interface. >> To talk about that point, I'm thinking of always using tagged types >> instead of legacy records, so as to be able to hide or expose the typ= e >> definition without consequences on the client side, or even just chan= ge >> the layout. That's more resilient: if you have three properties A, B,= C, >> where one is derived from the two other, say C is derived from A and = B, >> and then decide later that instead C will be stored and B derived fro= m A >> and C, you can do that without breaking client, if you use tagged = >> records > > How? > >> (you can't with legacy record). > > Why not? > Shifting from the initial topic, but let's go for that new one. 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 (maintenance and re-factoring always happens, sooner or later), = someone notice C is a function of A and B, and should not be stored in t= he = (legacy) record, but derived from A and B. 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 :=3D 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 reco= rd = 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 :=3D X.C; Just does not work with procedure, though. Thus X.C :=3D Y Will still be broken, even with a tagged record, which does not solve th= at = case. Honestly, there is another way, which is to never expose record fields i= n = public part, and always use function/procedure. But that tends to produc= e = the same issue has the one which was solved with the introduction of the= = =E2=80=9Cuse type=E2=80=9D clause. When I do =E2=80=9CX.C=E2=80=9D, I se= e it as the same as what =E2=80=9Cuse = type=E2=80=9D do. 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). -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [1] [1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers= ity