Re: Inherited Methods and such

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 19 Sep 2007 15:13:06 -0700, Maciej Sobczak wrote:

> On 19 Wrz, 17:16, "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:

A. The language is untyped, as you cannot name the object's type, or else

B. There exists a type T3, such that T1<:T3 and T2<:T3, (with the domain
set containing both the value before and the value after change). This
third type of the object does not change, and the type of the object is
neither T1, nor T2, but T3.

>>> This is what justifies the concept of "dynamic type".
>>
>> No it does not. How does a dynamic type behave?
> 
> Dynamically.

Huh, let us take this and consider the predicate "dynamically". Then:

   forall x of T, dynamically(x)

I.e. dynamically(T) is invariant.

There is always a common denominator of the behavior for any per-design
identified set of values associated with an object. In a typed language
this and only this behavior is described by the object's type. For this
reason any object has exactly one type. No more, no less.

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?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de