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,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d80cdc1b3ff5b2f9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-14 15:30:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!diablo.theplanet.net!news.theplanet.net!not-for-mail From: "Stephen Cole" Newsgroups: comp.lang.ada Subject: Re: Simple Question 3 Date: Sun, 14 Oct 2001 23:30:56 +0100 Message-ID: <9qd3lm$5d$1@news6.svr.pol.co.uk> References: <9qcmt9$8n1$1@newsg1.svr.pol.co.uk> <2Fny7.17385$gT6.10077588@news1.rdc1.sfba.home.com> NNTP-Posting-Host: modem-1114.llama.dialup.pol.co.uk X-Trace: news6.svr.pol.co.uk 1003098614 173 217.135.180.90 (14 Oct 2001 22:30:14 GMT) NNTP-Posting-Date: 14 Oct 2001 22:30:14 GMT X-Complaints-To: abuse@theplanet.net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:14493 Date: 2001-10-14T22:30:14+00:00 List-Id: wrote in message news:2Fny7.17385$gT6.10077588@news1.rdc1.sfba.home.com... > > question of what a primitive operation is! Is it a function/procedure which > > takes a derived type parameter and/or returns a derived type? Or is it just > > functions which return a derived type only? > The former. > > Why does returning a derived type seem to have > > more rules about what must be later declared in a derived type, than > > function/procedures that just take that derived type as a parameter? > > ... > > The way the compiler is behaving, its as if it only takes into account > > "out" parameters and does not care what "in" parameters look like. > If an object of MyTestType1 is an input parameter to a function or > procedure, it's safe to inherit since the function/procedure will simply > not know about, and thus ignore, any later extensions in objects of > type MyTestType2. If it's an output result, however, the function > or procedure needs to be able to create an object with all of its > extensions values. That is only possible if the function/procedure > is declared after MyTestType2 is declared, so it knows about those > extensions and can set them to appropriate values. Why does it need to create them all? I would understand this if it was returning a class wide type, but not a concrete defined type. One function should be enough. And any calls for this "missing" function should cause a dynamic or static error to occur. > > > function UnitA(a: MyTestType1) return Integer; > > function UnitB(a: MyTestType1) return MyTestType1; > > function UnitC return MyTestType1; > > UnitA() does not get flagged by the compiler as needing to be declared for > > MyTestType2. But UnitB() and UnitC() do! But they all hold enough type > > information for the compiler to be "intelligent" enough to know where static > > matching takes place or not. > Yes indeed, the compiler does know whether static matching takes place. > It sounds like you want the compiler to flag any *use* of UnitB or UnitC > where the left side of the assignment statement does not match, but > you want the compiler to allow the *declaration*. Right? Not really. What I mean is Why the separate ruling for UnitA() and UnitB(), UnitC() when it comes to what must be redeclared in terms of the derived type? This question all started for me with asking whether a function needed to be fully decleared for all future derived types if it was declared as abstract in the base type. But now I see another situation where you *must* redeclare a function, and it looks like you must declare it for the full hierarchy rooted at the base type. This seems odd. And I'd just like to understand the reason why this is. > If you were painting the floor in a room, you might like to paint a > thin part just inside the doorway, knowing that you could step over it > and get out of the room. The compiler is saying, "whoa, you can't > start your painting from just inside the doorway because you'll paint > yourself into a corner". It's easy enough to avoid the problem by > standing outside the doorway to do your painting. Similarly, as > pointed out by Jean-Marc Bourguet, there are easy ways to declare Unit > as a non-primitive operation. I think you are talking about where function/procedures are declared (painted) relative to the derived record types themselves. Are you? This must be after the type as the compiler *sees* things sequentially from top to bottom. This makes sense. Its just the *demand* by the compiler for me to redeclare a function/procedure just for reason of what type it returns, which is throwing me.