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: 103376,fa22a73e140a6fd1,start
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.74.201 with SMTP id w9mr8565537pbv.0.1326026700790;
        Sun, 08 Jan 2012 04:45:00 -0800 (PST)
Path: 
 lh20ni156200pbb.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!news.internetdienste.de!news.tu-darmstadt.de!news.belwue.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 08 Jan 2012 13:45:00 +0100
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US;
 rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Object-Oriented style question
Message-ID: <4f098fcb$0$6577$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 08 Jan 2012 13:44:59 CET
NNTP-Posting-Host: f4c9d206.newsspool3.arcor-online.net
X-Trace: 
 DXC=mU]NSQb;bBc:i=48;n?Z:`McF=Q^Z^V3h4Fo<]lROoRa8kF<OcfhCOk80[U>_ljHilPCY\c7>ejVh_bTc22X6AcoZ>_XCoo<7Dl
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-01-08T13:44:59+01:00
List-Id: <comp.lang.ada>

Given a tagged O-O type T in package Pak and a "method" of T,
called "Info". Method Info queries the state of its parameter,
which is of type T. States are of a type named "Value", which
also happens to be defined in Pak.

    function Info (Item : in T) return Value;
           -- queries status of Item

The primitive operation Info may be inherited when deriving
another type from Pak.T. A program that calls Info in an O-O style
may want the call to be dispatched to the inherited operation.

A client working with the T hierarchy could look like this:

    procedure Get_Info (Item : Pak.T'Class) is
    begin
       Status := Item.Info;  -- dispatching call
    end Get_Info;

where

    Status : Pak.Value;

My question is about the best way to declare the Info operation,
and its parameter profile in particular.

(A follow-up question is whether introduction to O-O programming
in Ada should be careful when mentioning plain "access" parameters.)

There is a number of alternative possibilities of declaring query
functions:

package Pak is

    type Value is range 1000 .. 1003;

    type T is abstract tagged private;

    function Info (Item : in T) return Value;
    function Info_1 (Item_Doubly_Indirect : access T) return Value;
    function Info_2 (Item_Doubly_Indirect : access constant T) return Value;
    function Info_3 (Item_Doubly_Indirect : not null access constant T) return Value;

private
    type T is tagged record
       Data : Value := Value'First;
    end record;
end Pak;

When evaluating the alternative possibilities of declaring
a query function such as Info, Info_1, Info_2, and Info_3---and
ignoring the fact that in some cases there might be technical  or other
issues that narrow the choices---I am thinking that the operations
Info and Info_3 are almost the same, insofar as the argument is
*read-only* in both cases, and the argument must be an *existing*
object in both cases.

Info_2 is still close to the meaning of a query function except
that the parameter may be null. This then means that there is *no*
object of type T'Class and, consequently, there cannot be a state!
Programs that call Info_2 could then needlessly raise an exception.
(If "null" is somehow important in a set of objects from
the T hierarchy, this does not preclude testing for "null",
since the test can be performed at the place in the program
where both the null pointer and the test are needed (and a default
state value assigned).)

Info_1 does not even express, at the language level, that Info_1
is a query: the query function has *write* access to the state
information. Arguably, this can be an invitation to introduce
obscure errors.

The above definitions are not even informally equivalent, then,
and, in particular, Info and Info_1 are the least alike.

Still, some recent program fragments seem to indicate that programmers
approaching O-O programming in Ada use Info_1 (with "access") for query
functions, IMHO the least preferable choice in the subjective evaluation
hierarchy above.

My guess is that the choice is caused by transporting knowledge acquired
when using a language that is different from most O-O languages,  since
most O-O languages do *not* use *explicit* "access" for declaring
O-O "methods" (Ada, Eiffel, Java, C#, OCaml, ...). Not even for
dispatching calls.  They have O-O mechanics built into the language
and translation helps with keeping O-O mechanics correct, and efficient.

I have effectively two questions, then, one concerning didactic
style and one concerning cost and robustness of using Ada:

First question: Will it be preferable if those introducing O-O
in Ada use a (virtual) rubber eraser and clean up introductions
by removing unneeded (and in some cases dangerous) "access" from
declarations of O-O primitive operations?

Second question: Technically, will it be advisable to work on
"access-free" bindings to O-O libraries because the Ada language
makes O-O types be by-reference as is?  Or on facilitating these
with the help of a compiler matching by-reference  mechanics of
foreign languages?