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,bf5045b7cee3d4b
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,UTF8
Path: 
 g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: tagged type as generic parameter
From: Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>
In-Reply-To: <fllb25$a70$1@news2.u-psud.fr>
References: <fliudg$14v$1@news2.u-psud.fr>
	 <xgdnrdjferbj.nn9l327fp4xn.dlg@40tude.net>  <fllb25$a70$1@news2.u-psud.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <1199452925.7932.37.camel@K72>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Date: Fri, 04 Jan 2008 14:22:05 +0100
Organization: Arcor
NNTP-Posting-Date: 04 Jan 2008 14:22:05 CET
NNTP-Posting-Host: 3ed731ca.newsspool4.arcor-online.net
X-Trace: 
 DXC=llY\TKBoTPMX36K@\WTHGJ4IUK<Cl32<A4Fo<]lROoRA4nDHegD_]REiU2CcZ[jJ@@A:ho7QcPOVC`h_T;28lonI3bKEI:E?PYB
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:19194
Date: 2008-01-04T14:22:05+01:00
List-Id: <comp.lang.ada>


On Fri, 2008-01-04 at 14:08 +0100, Philippe Tarroux wrote:
> Dmitry A. Kazakov a =C3=A9crit :
> >
> > The function A_Data returns Data. It is a primitive operation of Data a=
nd
> > thus covariant in the result. So when you derive anything from Data, yo=
u
> > have to override it in order to provide a correct implementation that w=
ould
> > return the derived type rather than the base.
> >  =20
> Ok. But does it mean that only the constructor is a primitive operation=20
> of the data type, not the print procedure? In this case why Print=20
> doesn't need to be redefined?

Data's Print operation works for objects of any type rooted at
Data. There is always a Data view of such an object.

OTOH, a function that is to return an object of a type
derived from Data will have to provide all components
of the derived type. That's not the LRM reason for the need
to override the function. But it should be a hint as to
why this need exists (the variance issue Dmitry has mentioned).

Imagine this

   Data
         function make (...) return Data;
    ^
    |  -- inheritance, IS A
  Special_Data


When you have a variable V of type Special_Data
and you call

  V :=3D make (...);

then---without an overridden make---this Make would have to be
the Make defined with type Data. However, the Make defined
with Data cannot return objects of type Special_Data, which
is needed.

OTOH, When you have a variable V of type Special_Data
and you call

  print(V);

there is no problem because Print works with Data
objects and V "IS A" Data object (its type is derived
from Data.) So Print views V as being of type Data,
not Special_Data, in a sense.

HTH, Georg