Re: Inherited Methods and such

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

On Thu, 20 Sep 2007 13:45:19 -0700, Maciej Sobczak wrote:

> On 20 Wrz, 18:22, "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.

> 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). It is not of T'Class because T and all
possible derived from it types shall be constructed before T'Class. In
fact, neither g(), nor f() can be called in a true constructor.

BTW, this is also the reason why people calling Ada's Initialize a
constructor are wrong. Initialize is not a constructor of either T or
T'Class.

Further, the type of *this is indeterminable, because I can explicitly call
the constructor at any stage of filling the dispatching table, the effect
will depend on the table. So either you commit *this to a mutating specific
type T or to static polymorphic type T'Class. But in either case the
contract is violated in T::T().

>>> 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.
2. If the identifier is the only permanent property of an object then it is
exactly what one understand under untyped. The only behavior you can
associate with the object is its identifier.

>> Even if you cast and per chance the address of the result is same (why
>> should anybody care?), it is a different object.
> 
> No, it's the same object. It's just fattening.
> Unless in your world people change their identity after fattening. :-)

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

>> Otherwise, you would have
>> to drop the concept of single type and go untyped.
> 
> If you limit yourself to these two options only, it's your limitation,
> not mine.
> I see a place for dynamically changing types. It is *single* in any
> given moment.

> It is still typed, because it is determined a priori,
> not by actual value.

See above.

> 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." In this case the
object is polymorphic and has exactly one type. The construction is the
following:

T={t1,t2,t3}
S={s1,s2}

Now if you know that X is either T or S. Then the type of X is

class {T,S}= { (T,t1), (T,t2), (T,t3), (S,s1), (S,s2) }

X does not mutate and its values are neither of T or of S, we cannot do
that without breaking strong typing.

> 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? Why not to demote/promote?

In Ada terms it would change the tag. It is difficult to implement but
consistent, under the assumption, that you do not change the type! The type
is T'Class. In the example above:

   X : class {T,S} := (T,t1);
begin
   X := (T,t2);
   X := (S,s1);  -- The type is not changed!

The contract of X is invariantly class {T,S}. The so-called specific type
of X changes, but it is not the true type of. It is the type of the second
component of its value. The true type is class {T,S}.

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