Re: Inherited Methods and such

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

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

> > My expectations are different during the lifetime of the object. Hence
> > - the behavior that I expect is time-variant. Hence - the type changes
> > over time. End of story.
>
> 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 ?

Whatever it is, your assumptions are still wrong.
There is no point in discussing the concept of "taking the value"
here, because the value is meaningful in the context of its type only.
The object under construction (in C++) changes its dynamic type *at
the same time* acquiring new components. This is crucial. The object
acquires new components while it traverses the constructor chain and
these new components obviously take part in value interpretation of
the whole.
There is no such thing as object of type T taking new value, nor the
value changing type. Neither value nor type is constant here. They
flow together as the object is progressively constructed/destructed
and every single moment in time the object has a valid value of *some*
type.

> Huh, let us take this and consider the predicate "dynamically". Then:
>
>    forall x of T, dynamically(x)
[...]

> For this
> reason any object has exactly one type. No more, no less.

Yes. Every single moment the object has one type. But the time is
passing and the object's classification flows together with time. This
can be observed with dispatching operations.

> One can argue for alternative notions of type and typed language, but they
> likely would not be consistent with behavioral point of view, which you
> have already subscribed to, or?

Or we get stuck with the idea that either T or value must be
invariant.
This is not true in C++.

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