Re: Inherited Methods and such

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 21 Wrz, 20:59, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >>>> If you say that an object of the type T1 can take values of the type T2,
> >>>> such that not T1<:T2, then either:
>
> >>> What is T1<:T2 ?
>
> >> Subsumption.
>
> > This I can guess. What is the direction?
>
> Any value of T1 is also one of T2.

OK. But then your initial usage of it (still cited above) is wrong in
case of constructor, because the type changes in the "more specific"
direction.

> > No, this is strongly typed, because the type is determined
> > declaratively and can be deduced without examining the value.
>
> If it were so, then
>
> class T
> {
>    T () { f(); g(); }
>    void g() {}
>    virtual void f() {}
>
> };
>
> should be illegal. Consider f() called in the constructor. The hidden
> parameter *this of is neither of T nor of T'Class:
>
> It cannot be of T, because T is not yet constructed (and you don't want to
> consider *this specific anyway).

Not exactly. In the constructor of T, *this already has type T.
Note that f() is called *after* initializing the fields (the
constructor initializer list serves some purpose!). Some invariants
might not be established yet, but the fields are supposedly already
initialized. The invariants are not an issue - functions calling each
other have to deal with this effect in general.

> It is not of T'Class

It is - T belongs to T'Class.

> In
> fact, neither g(), nor f() can be called in a true constructor.

No. Both can be called, because *this has type T. Both static and
dynamic.
This is actually the case where virtual calls can be inlined.

> BTW, this is also the reason why people calling Ada's Initialize a
> constructor are wrong.

Right. Ada doesn't have *any* constructors. :-)

> Further, the type of *this is indeterminable, because I can explicitly call
> the constructor

No, you cannot. Constructor is not a function - you cannot just "call"
it.
(So I cut out your wrong conclusions.)

> >>> Every single moment the object has one type. But the time is
> >>> passing and the object's classification flows together with time.
>
> >> Nope, the result is another object, *because* you cannot change the type.
>
> > It is always the same object, on the basis of its identifier, which is
> > invariant. By indentifier I take the address of the object.
>
> 1. You cannot take address because the object might be in cache.

What is "cache"? The C++ standard says nothing about it.
I can take the address of an object whenever I want.

> 2. If the identifier is the only permanent property of an object then it is
> exactly what one understand under untyped.

Which consistently means that you just got stuck with the idea that
type must be permanent.

Identifier is permanent and this allows me to say that the object
*persists* along the process (there is no object replacement, etc.).
The type evolves during this process.

> In my world people don't become whales upon fattening. At least not in one
> generation. (:-))

Good. :-)

What about growing up?
What about getting promoted in the company?

> > I *know* how the type will change without looking
> > at the value.
>
> If you *know* it, then the actual type of the object is a class containing
> the trace of all possible types the object would "take."

No. There is nothing that forces me to take this view. I don't need
any "actual" type, becuase the actual type is determined by the
progress along the inheritance chain.

> > It is completely different from assigning whatever value
> > to some object and saying that it changed its type as a result of
> > this.
>
> How is it different? Why the type can be changed upon construction, but
> cannot upon assignment?

Because the language recognizes the fact that construction/destruction
does not happen immediately and it is a "build-up" process. Assignment
is performed on the object that is already "established".

> Why not to demote/promote?

There are languages that support this.

> In Ada terms it would change the tag.

Yes.

> It is difficult to implement but
> consistent, under the assumption, that you do not change the type! The type
> is T'Class.

You can end up with Java-like Object'Class. Not much helpful.

I prefer the model offered by C++, because it allows the analysis of
code to be more reasonable. The objects have invariant types between
the end of their constructor and the beginning of their destructor. So
- a static set of objects exposes the property of static type system.
It's only the process of birth and death that is difficult and it is
when C++ prevents the programmer from dispatching to the function that
expects some fields to be initialized while they are not. I have never
found myself in a situation where that would make any difference (I
don't call virtual functions from constructors), but I find the model
to be more complete just by knowing that the problem can never happen.
Correctness by construction, anyone? ;-)

--
Maciej Sobczak
http://www.msobczak.com/