Re: Simple Question 3

["Stephen Cole" <s_k_cole@userat.freeserve.co.uk>]

<tmoran@acm.org> 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.