Re: Inherited Methods and such

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

On Thu, 20 Sep 2007 06:52:33 -0700, Maciej Sobczak wrote:

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

Subsumption.

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

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

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

Nope, the result is another object, *because* you cannot change the type.
Even if you cast and per chance the address of the result is same (why
should anybody care?), it is a different object. Otherwise, you would have
to drop the concept of single type and go untyped.

(BTW classification. "Type" is another word for "classification." Types
classify sets of values)

> This is not true in C++.

It is no matter how C++, Ada or PHP would define it. Because it is a model
that describes what is going on in the given language. Here the programming
language is just an object language, a subject. A model is only wrong when
it describes things incorrectly. If C++ calls type "class," that does not
bother me, naming conventions do not influence the model. Ada subtypes and
Liskov subtypes as known in CS have nothing in common either. So what?

The model I am talking about can describe C++, though it cannot describe it
in a way that some nice and desirable constraints, like object-type
bijection, statically determinable types, statically comparable types,
would necessarily hold. This classifies C++ as weakly typed, if not
untyped. Is that surprising?

The choice of a model is a question of personal preferences. I don't like
models where an object has many types but no values. It is
counterintuitive, and I believe inconsistent. Provided, somebody would take
care and tried to formalize such a mess.

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