comp.lang.ada
 help / color / mirror / Atom feed
From: Philippe Tarroux <philippe.tarroux@limsi.fr>
Subject: Re: tagged type as generic parameter
Date: Fri, 04 Jan 2008 16:38:40 +0100
Date: 2008-01-04T16:38:40+01:00	[thread overview]
Message-ID: <flljr1$er3$1@news2.u-psud.fr> (raw)
In-Reply-To: <1199452925.7932.37.camel@K72>

Georg Bauhaus a écrit :
> On Fri, 2008-01-04 at 14:08 +0100, Philippe Tarroux wrote:
>   
>> Dmitry A. Kazakov a écrit :
>>     
>>> The function A_Data returns Data. It is a primitive operation of Data and
>>> thus covariant in the result. So when you derive anything from Data, you
>>> have to override it in order to provide a correct implementation that would
>>> return the derived type rather than the base.
>>>   
>>>       
>> Ok. But does it mean that only the constructor is a primitive operation 
>> of the data type, not the print procedure? In this case why Print 
>> 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 := 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
>
>   
Thanks for your explanations. That's all clear for me now.

 I have missed this point which is similar to the one raised in Barnes 
about Geometry.Triangles. He suggests that a way to avoid the 
redefinition of the constructor when there is no need of it or when the 
constructor of the derived type hasn't the same structure of parameters, 
is to use a child function. In this case the function is not a primitive 
operation of the type.

I am going to look if it can apply to the present case.

Philippe



  reply	other threads:[~2008-01-04 15:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-03 15:20 tagged type as generic parameter Philippe Tarroux
2008-01-03 15:51 ` Dmitry A. Kazakov
2008-01-03 16:22   ` Adam Beneschan
2008-01-03 16:58     ` Dmitry A. Kazakov
2008-01-03 17:47       ` Jean-Pierre Rosen
2008-01-03 18:13         ` Pascal Obry
2008-01-03 19:20         ` Dmitry A. Kazakov
2008-01-03 21:37         ` Jeffrey R. Carter
2008-01-04 13:08           ` Philippe Tarroux
2008-01-04 15:03             ` Jean-Pierre Rosen
2008-01-04 13:08   ` Philippe Tarroux
2008-01-04 13:22     ` Georg Bauhaus
2008-01-04 15:38       ` Philippe Tarroux [this message]
2008-01-04 14:17     ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox