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,83568e4f0ce7998e
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Received: by 10.66.77.131 with SMTP id s3mr8003871paw.24.1351331448232;
        Sat, 27 Oct 2012 02:50:48 -0700 (PDT)
Path: 
 s9ni51564pbb.0!nntp.google.com!news.glorb.com!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: Alternative syntax for function definitions?
Date: Sat, 27 Oct 2012 11:50:39 +0200
Organization: cbb software GmbH
Message-ID: <15jzdp62q6hdp$.1u7hck0evmz22.dlg@40tude.net>
References: <op.wmtq0sipule2fv@cardamome>
 <aofcgnli1bud$.1ieeg4tvf6wt0.dlg@40tude.net> <op.wmtun2kuule2fv@cardamome>
 <en1cfkh3booj$.idqhb9xfwi97.dlg@40tude.net> <op.wmtx2nxkule2fv@cardamome>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: pSb85Ij4EqcuHDcWtw64BQ.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
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: 2012-10-27T11:50:39+02:00
List-Id: <comp.lang.ada>

On Sat, 27 Oct 2012 11:02:37 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sat, 27 Oct 2012 10:37:11 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> 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 type  
> definition without consequences on the client side, or even just change  
> 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 from A  
> and C, you can do that without breaking client, if you use tagged records  
> (you can't with legacy record). But I expect generalisation of use of  
> tagged types to impact efficiency with most compilers (although I'm  
> actually using only one).

The problem is conflation of the interface and implementation. Ada 83
record types are both interface and implementation. Which is OK only in the
private part of the package. In public interfaces it is a fragile design
the language unfortunately encourages.

This separation has nothing to do with tagged types, classes and
inheritance. It has no impact on efficiency other that different
implementations of the same interface could perform differently.

People are confusing these issues all the time.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de