Re: Inherited Methods and such

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 26 Wrz, 14:26, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>> And why "constructor functions" do not solve
>> it?
>
> Constructor functions in Ada are functions that return new objects
> (most useful for limited types since Ada 2005) can have parameters,
> but they still don't acknowledge the "progressive" nature of the whole
> process.

I think they do, actually.  At least, they can, if you program it that
way.  You can say (presuming T2 is derived from T1):

    function Make_T2 (...) return T2 is
    begin
        return Result : T2 := (Make_T1 (...) with ...) do
            ...
        end return;
    end Make_T2;

Within Make_T1, the 'Tag of its result will be T1'Tag,
even though that is really the parent part of the Result in T2,
whose Tag is T2'Tag.  And a call to this Make_T2 could
be the parent part of some other extension aggregate
in some other constructor function, with some other
(deeper) Tag.

>... This means that no matter whether we use Initialize or
> constructor functions, the final type of the object is established at
> the very beginning and is kept during the whole construction process.

You're right about Initialize, and I agree with you (I don't much like
it).  But constructor functions are different.

> If this process involves some activities on various levels of the type
> inheritance chain, the ugly effects like the one from my example can
> result, because primitive operations can be called bypassing the
> intended order of component construction.
>
>> Are there other languages (c++, perhaps?) that have a complete solution
>> to this problem?
>
> My claim in this lengthy and philosophical discussion is that C++
> provides a complete solution which can be shortly described like this:
> the final type is not established from the very beginning, but is
> progressively moving along the inheritance chain as the subsequent
> constructors of base types complete their work. Thank's to this,
> primitive operations never dispatch further than what can be
> statically reasoned about.

Well, I'd say that Ada is doing the same thing in my above example,
except it's not "changing" the Tag of a single object -- instead,
the result of Make_T1 has its Tag, and then Make_T2 has a different
Tag.  Within Make_T1, you can't dispatch to a T2 operation.

> Implementation-wise, this can be done with "just" changing the tag of
> the object as each base constructor completes.

Right.  Implementation-wise, the Tag of the result of Make_T1 is stored
at the same location in memory as the Tag of the result of Make_T2.
This memory location is overwritten after Make_T1 returns,
during the evaluation of the extension aggregate.  (Well, to
be precise, it's the same location if the type is limited.
For nonlimited, the implementation can choose to make them
the same location, or can copy things.)

- Bob