Re: Inherited Methods and such

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

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?

> > 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.
>
> Even better, so objects have no values, but many types...

No. Object has one value.

> > 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.
>
> Right, this is called untyped. The rest is handwaving.

No, this is strongly typed, because the type is determined
declaratively and can be deduced without examining the value. The
value has to always match the type, which is known a priori.

But I agree that there is some handwaving in this discussion.

> > 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.

And yes, the type *changes* while the object traverses along the chain
of constructions/destructions.

> 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. :-)

> 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. I *know* how the type will change without looking
at the value. It is completely different from assigning whatever value
to some object and saying that it changed its type as a result of
this. This is the point that you seem to be missing.


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