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!news3.google.com!proxad.net!feeder1-2.proxad.net!news.cs.univ-paris8.fr!u-psud.fr!not-for-mail From: Philippe Tarroux Newsgroups: comp.lang.ada Subject: Re: tagged type as generic parameter Date: Fri, 04 Jan 2008 16:38:40 +0100 Organization: University Paris-Sud, France. Message-ID: References: <1199452925.7932.37.camel@K72> NNTP-Posting-Host: osiris.limsi.fr Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news2.u-psud.fr 1199461025 15203 129.175.157.197 (4 Jan 2008 15:37:05 GMT) X-Complaints-To: newsmaster@u-psud.fr NNTP-Posting-Date: Fri, 4 Jan 2008 15:37:05 +0000 (UTC) User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <1199452925.7932.37.camel@K72> Xref: g2news1.google.com comp.lang.ada:19199 Date: 2008-01-04T16:38:40+01:00 List-Id: 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